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

[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

Re: [Pharo-project] snapshot methods

by Igor Stasenko

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 :) -- Best regards, Igor Stasenko.

Dec. 5, 2012

[Pharo-project] snapshot methods

by Camillo Bruni

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.

Dec. 4, 2012

[Pharo-project] Legacy FileDirectory

by Camillo Bruni

I finally found the motivation to properly package my compatibility package. http://smalltalkhub.com/#!/~dh83/fisleg/packages/FileSystem-Legacy For people who want to migrate to 2.0 but depend on FileDirectory, they can load this compatibility package for 2.0 which will add a mock FileDirectory. It will mostly forward to FileReference. This is legacy software and should only be used for migration ;) best cami

Dec. 4, 2012

Re: [Pharo-project] ConfigurationOfPetitParser has broken #'common' section

by Frank Shearar

Thanks Camillo, that's done the trick. I've found _another_ problems with the configuration, but that I can fix. (The configuration only works if you have a network connection.) I'll hopefully post a fix in the very near future. frank On 4 December 2012 21:54, Camillo Bruni <camillobruni(a)gmail.com> wrote: > hard to guess if I don't know the project :P > for me it worked you have all the parsing capabilities minus the debug UIs > > On 2012-12-04, at 18:51, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> Oh, I see a minimal Petit... But isn't that going to be too small? >> Alternatively why not a ConfigurationOfGrosParser ? >> >> Nicolas >> >> 2012/12/4 Camillo Bruni <camillobruni(a)gmail.com>: >>> just load the minimal group and you're fine. That's what we do in 2.0 as well... >>> >>> >>> On 2012-12-04, at 18:32, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>> >>>> By "broken" I mean "it might work fine in Pharo but it doesn't in Squeak". >>>> >>>> That's because PetitParser now uses Glamour, which pulls in a whole >>>> host of things that probably don't work in Squeak. (I don't know, I >>>> haven't tried, but these are all UI things, and the UI is where Pharo >>>> and Squeak are least compatible.) >>>> >>>> I'm being a bit rude in that I don't yet have a fix for the issue. >>>> Ideally, a ConfigurationOf would have Pharo specific stuff and Squeak >>>> specific stuff in separate sections, with only the shared things >>>> (right now, not Glamour, nor its dependents) in the #'common' section. >>>> >>>> However, if someone doesn't beat me to it, I'll submit a fix soon, >>>> once Squeak 4.4 is out the door. >>>> >>>> frank >>>> >>> >>> >> > >

Dec. 4, 2012

Re: [Pharo-project] ConfigurationOfPetitParser has broken #'common' section

by Camillo Bruni

hard to guess if I don't know the project :P for me it worked you have all the parsing capabilities minus the debug UIs On 2012-12-04, at 18:51, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Oh, I see a minimal Petit... But isn't that going to be too small? > Alternatively why not a ConfigurationOfGrosParser ? > > Nicolas > > 2012/12/4 Camillo Bruni <camillobruni(a)gmail.com>: >> just load the minimal group and you're fine. That's what we do in 2.0 as well... >> >> >> On 2012-12-04, at 18:32, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> >>> By "broken" I mean "it might work fine in Pharo but it doesn't in Squeak". >>> >>> That's because PetitParser now uses Glamour, which pulls in a whole >>> host of things that probably don't work in Squeak. (I don't know, I >>> haven't tried, but these are all UI things, and the UI is where Pharo >>> and Squeak are least compatible.) >>> >>> I'm being a bit rude in that I don't yet have a fix for the issue. >>> Ideally, a ConfigurationOf would have Pharo specific stuff and Squeak >>> specific stuff in separate sections, with only the shared things >>> (right now, not Glamour, nor its dependents) in the #'common' section. >>> >>> However, if someone doesn't beat me to it, I'll submit a fix soon, >>> once Squeak 4.4 is out the door. >>> >>> frank >>> >> >> >

Dec. 4, 2012