October 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] NativeBoost FFI

by Nicolas Cellier

Hi Ciprian, I ran into same problem when I tried to interface Lapack with FFI a few years ago. So I used this simple idea to let the Compiler automatically pass an array of arguments, with two variants - hacked the compiler - subclassed the compiler See http://code.google.com/p/smallapack/wiki/SmallapackPortingOnSqueak http://bugs.squeak.org/view.php?id=2918 http://www.squeaksource.com/MetacelloRepository/ConfigurationOfSmallapack-n… http://www.squeaksource.com/Smallapack.html http://www.squeaksource.com/Smallapack/Smallapack-Compiler.trunk-nice.6.mcz Nicolas 2012/10/21 Ciprian Teodorov <ciprian.teodorov(a)gmail.com>: > Hi guys, > > Over the weekend I had a look at NativeBoost FFI and I have enjoyed it. I > really like this idea of taming the beast from high-level languages. > However I ran into some problems with the number of arguments one can pass > to a smaltalk method (it turns out to be 15 at max)... That bad for FFI > especially when you want to interface with legacy c code without touching > the C-stuff (header, object files, etc). > > In consequence I've hacked my way around this limitation by introduction of > a new type of arguments that we can pass to callouts. I call these arguments > "in object arguments". > The idea isn't new and is very simple, instead of passing 20 arguments to > your function just pass one an array with all the arguments you need. > Where it turns interesting is that I think we can pass more than just an > array we can pass real objects (think about ParameterObject) that hold in > their instance variables the arguments we want. > > lets say that we want to call a function " int function(int x, int y)", now > with the NativeBoost wrapper we will get a call something like > > function_x: x y: y > <primitive: #primitiveNativeCall module: #NativeBoostPlugin> > ^ self call: #( int function (int x, int y)) > > the idea is to replace x: y: with only one argument > > function: anArgument > <primitive: #primitiveNativeCall module: #NativeBoostPlugin> > ^ self call: #( int function (int anArgument@1, int anArgument@2)) > > or even > > function: aPoint > <primitive: #primitiveNativeCall module: #NativeBoostPlugin> > ^ self call: #( int function (int aPoint@x, int aPoint@y)) > > Yes this last example breaks the encapsulation a little bit by acceding > directly to the instance variable of aPoint... but... well > > another example will be: > > function_arg1: a arg2: b > <primitive: #primitiveNativeCall module: #NativeBoostPlugin> > ^ self call: #( int function (int a@1, int a@2, int b@3, int b@1, int a@6)) > > > Well that's all that I did this weekend. > > Attached to this mail you can find a file-out of these developments... they > include: > 1. the idea presented above > 2. refactoring of NBFFICallout argument loader creation > 3. a small "extension/fix" of the skipSpace method (in spec parser) to skip > all separators not just spaces (think about a header definition with tabs) > > Well that's it folks, enjoy > Cheers > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro

Oct. 21, 2012

Re: [Pharo-project] Parsing Smalltalk Array/Object Literals

by Igor Stasenko

On 21 October 2012 22:21, GÃ¶ran Krampe <goran(a)krampe.se> wrote: > Hey! > > > On 10/21/2012 04:21 PM, StÃ©phane Ducasse wrote: >> >> Well we started with ezequiel to work on that. >> We took a look at Deltas: >> - any change is revertible and keeps it changes >> >> Ezequiel was planning to show to the group what he has friday but we were >> busy. >> he will show us that tomorrow. > > > Ehrm?? Are you looking at Deltas? I haven't seen a single email, I would > love to at least be in the "consulting loop" on this - it is my baby after > all and I can answer most questions about it. > > >> Now I would really like that we do not have hack change set, whateverâ¦. >> But write something new aside. > > > Please, please, please - if you plan to replace ChangeSet (and you *should*) > - please take Deltas and run with it. It was *built* for that and I think a > lot of the code in there is good code and a nice design. > > And if you think some other file format is better - I don't care - that is > just serialization after all. And Tirade is of course not hard coded into > Deltas. To me the one of important part of this story is to have better code reuse. I like the idea of (re)using regular smalltalk parser to do heavylifting, while rest is built on top of it. I like the idea with Deltas that you can rewind them or play them. Now the problem is that it will require substantial effort to adopt it to Pharo. Not long ago, we introduced SystemAnnouncer, and if you look at announces (SystemAnnouncement subclasses) you can see that it very closely resembling delta records. I dont think that it will be clever to have two classes per each system event, i.e. ClassRemoved and then ClassRemovedDelta. It would be much nicer to have a single one. Another thing is what to do with SystemEditor? My main problem with it, that it is gone too far, trying to resemble many Class/Behavior protocols. That means that any change/extension in Class/Behavior will have potential risk breaking SystemEditor, if we forget to sync changes there as well. And the last time we did pass on SystemEditor, if i remember, there was still no support for traits. But sure thing, i should not forget to say about what SystemEditor gives: atomic updates. My only concern is that price for having such feature is a bit too high as to me: - big and complex (okay, non-trivial ;) ) logic - a maintenance needed if we go and hack Class/Behavior/Traits etc). for the other features, i don't see significant advantage of using it over something else (less complex and more compact). -- Best regards, Igor Stasenko.

Oct. 21, 2012

Re: [Pharo-project] Parsing Smalltalk Array/Object Literals

by Sven Van Caekenberghe

Dale, Please, please look at the code. Again: no my code does _not_ depend on a Smalltalk compiler. And indeed, there are 2 steps: 1. String -> Array Literal 2. Object Literal -> Object All in all, its very little code. Sven On 21 Oct 2012, at 20:23, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Sven, > > I'm not asking about the parser for the literal array but the parser to parse the literal array itself, but I think you've answered my question (indirectly:) > > The original reason for going with JSON 9 months ago was that since GemStone does not have a accessible parser for Smalltalk syntax, I need to choose an export format for "objects" that included a portable parser for the syntax ... > > Presumably your implementation assumes the existence of a Smalltalk literal parser (I think that is what I was able to glean from Igor's mails) in which case I won't be able to use it (even if I thought it was usable from a readability standpoint:). > > Dale -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Oct. 21, 2012

Re: [Pharo-project] source code management (was "Parsing Smalltalk Array/Object Literals")

by Craig Latta

Hi Igor-- > i now modelling a system logger (to replace .changes file), and since > i having no better idea, i'll try to use object literals for it. > > ... > > I took a look at current stuff in CompiledMethod 'source code > management' and it makes me vomit... Yay, glad you've joined the club! :) Unsurprisingly, I advocate for storing everything as objects: augment whatever textual log you have with a small dedicated object memory that records everything you do in your working memory[1]. When both sides of the conversation are Smalltalk memories, you can do the serialization as live remote messages, rather than having to do a static serialization as with storeOn:, BOSS, Fuel, etc. -C [1] http://tinyurl.com/8f5zq85 -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547 (no SMS)

Oct. 21, 2012

Re: [Pharo-project] Parsing Smalltalk Array/Object Literals

by Igor Stasenko

Guys, guys.. calm down. I'm not going to reinvent the wheel. What i am trying to do is to prototype the interface of external log. The contents of log is not particularly important to me at this stage, because i wanna first try to see if following model good enough: - logs will be stored in subdirectory, instead of single file. A directory name is ./imageFileName.sessionLog/ for each new session, a new file will be created. The file name format will be something like: <sessionId>-<date>.log what will be stored there (like example which i given) is mostly a speculation right now. First, i wanna make a sketch of this idea and see, how far we can go with it (what advantages/disadvantages). -- Best regards, Igor Stasenko.

Oct. 21, 2012

Re: [Pharo-project] For the Emacs fans: Shampoo

by dimitris chloupis

use it and help improve it looks to me like a healthy compromise ;) ________________________________ From: Frank Shearar <frank.shearar(a)gmail.com> To: Pharo-project(a)lists.gforge.inria.fr Sent: Sunday, 21 October 2012, 16:39 Subject: Re: [Pharo-project] For the Emacs fans: Shampoo On 20 October 2012 20:46, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > Begin forwarded message: > >> Subject: [Lsehub-staff] For the Emacs fans: Shampoo >> Date: October 20, 2012 9:45:14 PM GMT+02:00 >> >> http://dmitrymatveev.co.uk/shampoo/ Thanks, Marcus! I'm now torn between being happy that someone wrote such a thing, and being sad that I didn't write such a thing (first). And it's MIT-licenced! frank > -- > Marcus Denker -- http://marcusdenker.de > >

Oct. 21, 2012

Re: [Pharo-project] For the Emacs fans: Shampoo

by laurent laffont

git clone https://github.com/dmatveev/shampoo-emacs is better Laurent On Sun, Oct 21, 2012 at 10:20 PM, laurent laffont <laurent.laffont(a)gmail.com > wrote: > http://dmitrymatveev.co.uk/shampoo/files/shampoo-emacs-0.0.1.tar.gz > > => 404 not found :( > > Laurent > > > On Sun, Oct 21, 2012 at 2:18 PM, dimitris chloupis <thekilon(a)yahoo.co.uk>wrote: > >> >> great stuff indeed. Thanks for sharing. >> >> ------------------------------ >> *From:* Marcus Denker <marcus.denker(a)inria.fr> >> *To:* "Pharo-project(a)lists.gforge.inria.fr Smalltalk" < >> Pharo-project(a)lists.gforge.inria.fr> >> *Sent:* Saturday, 20 October 2012, 22:46 >> *Subject:* [Pharo-project] For the Emacs fans: Shampoo >> >> >> >> Begin forwarded message: >> >> > Subject: [Lsehub-staff] For the Emacs fans: Shampoo >> > Date: October 20, 2012 9:45:14 PM GMT+02:00 >> > >> > http://dmitrymatveev.co.uk/shampoo/ >> > >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> >> >> >> >

Oct. 21, 2012

Re: [Pharo-project] Parsing Smalltalk Array/Object Literals

by GÃ¶ran Krampe

On 10/21/2012 08:23 PM, Dale Henrichs wrote: > Sven, > > I'm not asking about the parser for the literal array but the parser to parse the literal array itself, but I think you've answered my question (indirectly:) > > The original reason for going with JSON 9 months ago was that since GemStone does not have a accessible parser for Smalltalk syntax, I need to choose an export format for "objects" that included a portable parser for the syntax ... > > Presumably your implementation assumes the existence of a Smalltalk literal parser (I think that is what I was able to glean from Igor's mails) in which case I won't be able to use it (even if I thought it was usable from a readability standpoint:). > > Dale I am sounding like a broken record - but Tirade includes a hand coded object literal parser which is fast. All of Tirade is 500 lines. But yes, it does reuse (IIRC) the parser for literal numbers, so you would need to implement/port that one... ;) regards, GÃ¶ran

Oct. 21, 2012

Re: [Pharo-project] Parsing Smalltalk Array/Object Literals

by GÃ¶ran Krampe

Hey! On 10/21/2012 04:21 PM, StÃ©phane Ducasse wrote: > Well we started with ezequiel to work on that. > We took a look at Deltas: > - any change is revertible and keeps it changes > > Ezequiel was planning to show to the group what he has friday but we were busy. > he will show us that tomorrow. Ehrm?? Are you looking at Deltas? I haven't seen a single email, I would love to at least be in the "consulting loop" on this - it is my baby after all and I can answer most questions about it. > Now I would really like that we do not have hack change set, whateverâ¦. > But write something new aside. Please, please, please - if you plan to replace ChangeSet (and you *should*) - please take Deltas and run with it. It was *built* for that and I think a lot of the code in there is good code and a nice design. And if you think some other file format is better - I don't care - that is just serialization after all. And Tirade is of course not hard coded into Deltas. Please. regards, GÃ¶ran

Oct. 21, 2012

Re: [Pharo-project] For the Emacs fans: Shampoo

by laurent laffont

http://dmitrymatveev.co.uk/shampoo/files/shampoo-emacs-0.0.1.tar.gz => 404 not found :( Laurent On Sun, Oct 21, 2012 at 2:18 PM, dimitris chloupis <thekilon(a)yahoo.co.uk>wrote: > > great stuff indeed. Thanks for sharing. > > ------------------------------ > *From:* Marcus Denker <marcus.denker(a)inria.fr> > *To:* "Pharo-project(a)lists.gforge.inria.fr Smalltalk" < > Pharo-project(a)lists.gforge.inria.fr> > *Sent:* Saturday, 20 October 2012, 22:46 > *Subject:* [Pharo-project] For the Emacs fans: Shampoo > > > > Begin forwarded message: > > > Subject: [Lsehub-staff] For the Emacs fans: Shampoo > > Date: October 20, 2012 9:45:14 PM GMT+02:00 > > > > http://dmitrymatveev.co.uk/shampoo/ > > > > -- > Marcus Denker -- http://marcusdenker.de > > > > >

Oct. 21, 2012