- Pharo-dev - lists.pharo.org

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

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

by Igor Stasenko

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

Re: [Pharo-project] NBFFICallback fnSpec

by Igor Stasenko

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 any help. > > Jimmie > -- Best regards, Igor Stasenko.

Dec. 5, 2012

[Pharo-project] NBFFICallback fnSpec

by Jimmie Houchin

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? I do not know C at all. Is the NBExternalString suitable for the const char *rowID? The documentation says you can use it for char*, but I don't know what difference const makes. Thanks for any help. Jimmie

Dec. 5, 2012

Re: [Pharo-project] Open Source and Constraints | Documentation is King

by Igor Stasenko

On 4 December 2012 12:57, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > But I think we do agree ;-) > > What makes me value tests a bit above documentation (but not so much that I am saying that documentation is not important), are two things: > > - tests are machine enforceable/controllable > - you can find them exactly using senders or references > well, a test is more direct and concise way of telling how your stuff works (or should work), as well as serving as a source of example. what you write in a test, could take like 10 times more explaining same in docs. still. with tests you cannot tell: - why it is done like that - what are responsibilities of components and how you can change/replace them if needed. - what is best/recommended practices to use your software - where the starting/entry point. -- Best regards, Igor Stasenko.

Dec. 5, 2012

Re: [Pharo-project] snapshot methods

by Camillo Bruni

On 2012-12-04, at 21:08, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 5 December 2012 00:48, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> I am always confused about the snapshot behavior. >> Yes, it returns true when we are in the new image, but this is far from obvious :/. >> >> How about a more explicit method for snapshotting and continue with different code >> in the new / old image: >> >> >> self stuffInCurrentImage. >> >> Smalltalk >> snapshotIfNew: [ self stuffInNewImage ] >> IfCurrent: [ self stuffInCurrentImage ] >> >> self stuffInCurrentAndNewImage. >> > > +1 > just > s/image/session/g yes makes more sense ;), ok I'll add it then :)

Dec. 5, 2012