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

Re: [Pharo-project] An excellent news

by Sven Van Caekenberghe

On 05 Dec 2012, at 09:43, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Excellent news! > > Doru +100 Indeed, very good news. Thank you, INRIA. > On Wed, Dec 5, 2012 at 9:41 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > We mentioned it in the past but now this is really official. To support the consortium, Inria is paying one full year > to Igor Stasenko. > > We want to thank Inria for its continuous support. > > Stef > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Dec. 5, 2012

[Pharo-project] PharoConf 2013 @ Bern?

by StÃ©phane Ducasse

Hello Pharoers The software composition group of the university of Bern proposed to organize the next pharo conf at berne during the week of 2-3 of April 2013. We are really happy of this proposal. Now we would like to know what you think about it before committing to the date and location. The Pharo board and crew

Dec. 5, 2012

Re: [Pharo-project] An excellent news

by Tudor Girba

Excellent news! Doru On Wed, Dec 5, 2012 at 9:41 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > Hi guys > > We mentioned it in the past but now this is really official. To support > the consortium, Inria is paying one full year > to Igor Stasenko. > > We want to thank Inria for its continuous support. > > Stef > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 5, 2012

[Pharo-project] An excellent news

by StÃ©phane Ducasse

Hi guys We mentioned it in the past but now this is really official. To support the consortium, Inria is paying one full year to Igor Stasenko. We want to thank Inria for its continuous support. Stef

Dec. 5, 2012

Re: [Pharo-project] NBFFICallback fnSpec

by Max Leske

On 05.12.2012, at 07:15, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > On 12/4/2012 8:48 PM, Igor Stasenko wrote: >> On 5 December 2012 03:22, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: >>> Hello, >>> >>> I am working through implementing NativeBoost interface to a C wrapper dll. >>> >>> I have 8 callback functions to call in this interface. I am subclassing >>> NBFFICallback as stated in the documentation. I am also implementing the >>> fnSpec method based on the code in the header file. >>> >>> fnSpec >>> >>> ^#( void (NBExternalString rowID, Row rowData)) >>> >>> This is the code in the header: >>> >>> typedef void (*TABLE_ROW_CALLBACK)(const char *rowID, FXCHandle rowData); >>> >>> >>> Should I leave the return type as void or should I use NBVoid? >>> >> Either will work. >> As long as >> NBFFICallout new resolveType: 'void' >> and >> NBFFICallout new resolveType: 'NBVoid' >> returning same object(s). >> >>> I do not know C at all. Is the NBExternalString suitable for the const char >>> *rowID? >> NBExternalString is a coverter which takes a pointer and turns it into >> ByteString instance. >> >> But you can use just 'String' as a type qualifier, which is alias for >> NBExternalString: >> >> String class>>asNBExternalType: gen >> >> ^ gen resolveType: #NBExternalString >> >>> The documentation says you can use it for char*, but I don't know what >>> difference const makes. >>> >> The const modifier matters for C compiler that guarantees that no >> attempts to write at pointer location >> will be made.. which is of course get lost when you cross language >> boundaries and therefore doesn't makes sense specifying in function >> signature. >> >> NBExternalString takes a pointer as input and then creates an instance >> of ByteString object >> and copies contents of C string in newly created object. >> From that perspective it fits well with 'const char *' type, because >> at language side you never obtain a >> real pointer to the string, but just a copy with string contents, and >> even if you will try to modify that string, you will be modifying a >> copy, but not original. >> >> P.S. if you load NativeBoost-Help package, there is a page describing >> in detail how type system >> and type resolution works. >> >> You can read help using >> NBHelp open >> >> or just open a help browser.. >> >> There could be some glitches loading markdown parser (which i had few >> days ago).. so if it will fail to work, then you can read from sources >> here: >> NBHelpOnFFI class>>types / types2 > Thanks for the help and information. > I wasn't expecting an answer quite so quickly. I can't tell if you sleep? :) > > I haven't been able to get the NBHelp to work yet. > In a freshly downloaded NBCog-VM and Pharo-2.0.image after installing NB and NBHelp. > When I do, NBHelp open. It starts installing but can't get past petitmarkdown. > There's a new thread on the list about the configuration of PetitParser being broken. This is probably what trips up loading the NB help ("ConfigurationOfPetitParser has broken #'common' section"). Cheers, Max > I don't know if it is a momentary SS3 problem or what. I'll try again in the morning after I get some sleep. > > Again, thanks. > > Jimmie >

Dec. 5, 2012

Re: [Pharo-project] The monkey is back in town

by Sven Van Caekenberghe

Yes, we love the monkey and missed him â¦ On 05 Dec 2012, at 04:43, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I had a sudden urge to program something so I revived the monkey (partly) > > - full smalltalk implementation (no more ruby) > - basic command line handler (could be better but works..) > - using OSProcess with FileSystem-Legacy in 2.0 > > the only thing missing are the couple of changes I proposed for the main image: > > - http://code.google.com/p/pharo/issues/detail?id=7097 > - http://code.google.com/p/pharo/issues/detail?id=7096 > - http://code.google.com/p/pharo/issues/detail?id=7095 > > once they are in, we're ready to roll > cami on fernet

Dec. 5, 2012

[Pharo-project] [update 2.0] #20428

by Marcus Denker

20428 ----- Issue 7097: VirtualMachine class improvements http://code.google.com/p/pharo/issues/detail?id=7097 Issue 7095: Add GoferResolvedReference >> #merge method http://code.google.com/p/pharo/issues/detail?id=7095 Issue 7096: Better option protocol for CommandLineHandler http://code.google.com/p/pharo/issues/detail?id=7096 Issue 7094: Removing some Object methods http://code.google.com/p/pharo/issues/detail?id=7094 Diff information: http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.997.diff http://ss3.gemstone.com/ss/Pharo20/Tests-MarcusDenker.487.diff http://ss3.gemstone.com/ss/Pharo20/System-Support-MarcusDenker.752.diff http://ss3.gemstone.com/ss/Pharo20/System-CommandLine-MarcusDenker.65.diff http://ss3.gemstone.com/ss/Pharo20/Morphic-MarcusDenker.1297.diff http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1263.diff http://ss3.gemstone.com/ss/Pharo20/Gofer-Core-MarcusDenker.189.diff

Dec. 5, 2012

Re: [Pharo-project] NBFFICallback fnSpec

by Jimmie Houchin

On 12/4/2012 8:48 PM, Igor Stasenko wrote: > On 5 December 2012 03:22, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: >> Hello, >> >> I am working through implementing NativeBoost interface to a C wrapper dll. >> >> I have 8 callback functions to call in this interface. I am subclassing >> NBFFICallback as stated in the documentation. I am also implementing the >> fnSpec method based on the code in the header file. >> >> fnSpec >> >> ^#( void (NBExternalString rowID, Row rowData)) >> >> This is the code in the header: >> >> typedef void (*TABLE_ROW_CALLBACK)(const char *rowID, FXCHandle rowData); >> >> >> Should I leave the return type as void or should I use NBVoid? >> > Either will work. > As long as > NBFFICallout new resolveType: 'void' > and > NBFFICallout new resolveType: 'NBVoid' > returning same object(s). > >> I do not know C at all. Is the NBExternalString suitable for the const char >> *rowID? > NBExternalString is a coverter which takes a pointer and turns it into > ByteString instance. > > But you can use just 'String' as a type qualifier, which is alias for > NBExternalString: > > String class>>asNBExternalType: gen > > ^ gen resolveType: #NBExternalString > >> The documentation says you can use it for char*, but I don't know what >> difference const makes. >> > The const modifier matters for C compiler that guarantees that no > attempts to write at pointer location > will be made.. which is of course get lost when you cross language > boundaries and therefore doesn't makes sense specifying in function > signature. > > NBExternalString takes a pointer as input and then creates an instance > of ByteString object > and copies contents of C string in newly created object. > From that perspective it fits well with 'const char *' type, because > at language side you never obtain a > real pointer to the string, but just a copy with string contents, and > even if you will try to modify that string, you will be modifying a > copy, but not original. > > P.S. if you load NativeBoost-Help package, there is a page describing > in detail how type system > and type resolution works. > > You can read help using > NBHelp open > > or just open a help browser.. > > There could be some glitches loading markdown parser (which i had few > days ago).. so if it will fail to work, then you can read from sources > here: > NBHelpOnFFI class>>types / types2 Thanks for the help and information. I wasn't expecting an answer quite so quickly. I can't tell if you sleep? :) I haven't been able to get the NBHelp to work yet. In a freshly downloaded NBCog-VM and Pharo-2.0.image after installing NB and NBHelp. When I do, NBHelp open. It starts installing but can't get past petitmarkdown. I don't know if it is a momentary SS3 problem or what. I'll try again in the morning after I get some sleep. Again, thanks. Jimmie

Dec. 5, 2012

Re: [Pharo-project] How to write a help in a geeky way :)

by Camillo Bruni

yes please! :) On 2012-12-05, at 00:14, Igor Stasenko <siguctua(a)gmail.com> wrote: > MyHelp class>>topicAboutWritingHelpTopicInGeekyWay > > ^ self topicTitle: 'How to write help in geeky way' contents: > > 'There''s nothing special, since help system expects string to be > returned, which is then converted to text > and shown to user.. And who said that this method should contain the > same text which you displaying? > > Sometimes, when you have some list of rules, which sits in a single > class (like list of default options > with short description for each of them, you can, of course copy and > paste the list, format it more appropriate for reader > and voila.. you got your page.. But downside of copying is that you > will have to maintain two copies of same thing and have to sync > them for the rest of your life. So, here a geeky way to avoid > duplication effort: ' , > > self extractCommentsFromCode: ( MyClass >> #myMethodWhereIPutOptions ) > , > ' and of course, i can continue here putting some more text, if > needed.. but i think i made it clear already how you can > make your help system to stay more up to date when you updating the code ;)' > > ------ > > This is Spar... err smalltalk! :) > > -- > Best regards, > Igor Stasenko. >

Dec. 5, 2012

[Pharo-project] The monkey is back in town

by Camillo Bruni

I had a sudden urge to program something so I revived the monkey (partly) - full smalltalk implementation (no more ruby) - basic command line handler (could be better but works..) - using OSProcess with FileSystem-Legacy in 2.0 the only thing missing are the couple of changes I proposed for the main image: - http://code.google.com/p/pharo/issues/detail?id=7097 - http://code.google.com/p/pharo/issues/detail?id=7096 - http://code.google.com/p/pharo/issues/detail?id=7095 once they are in, we're ready to roll cami on fernet

Dec. 5, 2012