- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] NativeBoost with no access to sources

by Igor Stasenko

On 5 July 2013 16:09, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 05/07/2013 15:31, Igor Stasenko a Ã©crit : >> >> On 5 July 2013 15:22, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> On 5 July 2013 11:03, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>>> >>>> Could you rather test for unability to get the source of the method and >>>> raise a NB-defined error? So that I could write a fallback on non-NB >>>> code >>>> with a on: do:. Please :) >>>> >>>> (it would then both handle startup related errors and unreadable sources >>>> as >>>> well). >>>> >>>> And with a backport to 2.0, because the odds of seeing an Opal based >>>> solution on 2.0 are fairly low. >>>> >>> the problem is that you will get same error when you put wrong name >>> into signature >>> or when no sources avail e.g.: >>> >>> foo: bar >>> ^ self nbCall: #( void foo (int baz) ) >>> >>> will give same error (unable to find binding for name 'baz' in given >>> context). > > > Of course. I could do with having the same error for both and knowing that > when developping and testing I would get it for stupid syntax errors and in > production to handle a real situation. > > >>> If its fine to you, i can do it. > > > Maybe I can try myself to see if I can write, before entering that loader > stuff, a correct test which raises an error if the method source isn't > available. > > well, all you need is basicaly replace this: Error signal: 'Could not find accessor for variable named "' , argName , '" in ' , method name with: NBArgumentNotFound signal: argName .. or NBCannotBindName.. what name for exception? -- Best regards, Igor Stasenko.

July 5, 2013

Re: [Pharo-dev] NativeBoost with no access to sources

by Igor Stasenko

On 5 July 2013 16:09, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 05/07/2013 15:31, Igor Stasenko a Ã©crit : >> >> On 5 July 2013 15:22, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> On 5 July 2013 11:03, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>>> >>>> Could you rather test for unability to get the source of the method and >>>> raise a NB-defined error? So that I could write a fallback on non-NB >>>> code >>>> with a on: do:. Please :) >>>> >>>> (it would then both handle startup related errors and unreadable sources >>>> as >>>> well). >>>> >>>> And with a backport to 2.0, because the odds of seeing an Opal based >>>> solution on 2.0 are fairly low. >>>> >>> the problem is that you will get same error when you put wrong name >>> into signature >>> or when no sources avail e.g.: >>> >>> foo: bar >>> ^ self nbCall: #( void foo (int baz) ) >>> >>> will give same error (unable to find binding for name 'baz' in given >>> context). > > > Of course. I could do with having the same error for both and knowing that > when developping and testing I would get it for stupid syntax errors and in > production to handle a real situation. > > >>> If its fine to you, i can do it. > > > Maybe I can try myself to see if I can write, before entering that loader > stuff, a correct test which raises an error if the method source isn't > available. > > >>>> >>>> Is there a real, practical difference between "at compilation time" and >>>> "when receiving MethodAdded event"? i.e. is the complexity added in the >>>> compilation process worthwhile? >>>> >>> the problem is that you may not always receive MethodAdded event, >>> because different tools putting different meaning into "this should be >>> compiled silently". >>> This is outstanding issue in Pharo.. and that's the main reason why i >>> would go with compiler (like >>> that i have guarantee that instance of CompiledMethod is well-formed, >>> and don't need to rely on >>> 3-rd party toolchain to deliver notification to me. > > > You mean that hacking support into the third party compiler isn't 3rd party > toolchain :) > well, to me the compiler's behavior is much much more predictable comparing to chances that when you loading code with broken Monticello/RPackage or running test, you won't receive the event you expecting. > >>> and besides, we need such hook mechanism in Compiler anyways (for many >>> other use cases) >>> and so, it will be not "renting a Boeing for single passenger" >>> >> >> oh.. and i forgot about most important aspect of it: >> i don't wanna see >> <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: >> errorCode > >> in code, instead if wanna use >> >> <native> >> (or similar), >> which admit, much more concise, elegant and user-friendly, and hides >> unnecessary implementation detail. > > > I remember seeing people introducing syntax extensions inside smalltalk > methods in VisualWorks, would that work as well ? Customize on a per class / > per method which compiler we should use. > yes. But i don't wanna extend syntax in case of NB , obviously :) > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > -- Best regards, Igor Stasenko.

July 5, 2013

Re: [Pharo-dev] [Moose-dev] SourceCity works

by Alexandre Bergel

> NBXLib means it will be available only for linux ? No idea. Roassal 3d works on Windows and OSX so far. No idea about Linux. Alexandre > > > abergel wrote >> Hi Erwan and all, >> >> Just to make a few things clear about Roassal 3d vs SourceCity. >> >> We are currently working on Roassal 3d, which intends to be a nice layer >> at the top of NBOpenGL and NBXLib to easily create 3d scenes with cubes, >> lights, camera, interactions, zooming, translucent coloring, >> clicking/rotating/translating individual elements and so on. Everything >> that is good for Roassal is equally good for 3D Scene. >> >> Having a city-like visualization will be one of our first objectives since >> (i) it is a compelling use of 3D and (ii) it is easy to implement (at >> least the bases). We started to work on a CityBuilder, to easily create >> cities from objects and provided metrics. Ideally, it would be great to >> have SourceCity based on our effort. Not now since we have just started >> Roassal 3D, but on some point we should merge (this is similar in the 2d >> World with Mondrian and EyeSee moving from plain Morphic to Roassal). >> >> Our objective is to offer a great 3d framework to make a truly flying >> SourceCity. >> Does this make sense to you? >> >> Cheers, >> Alexandre >> >> >> >> On Jul 4, 2013, at 10:47 AM, Erwan Douaille < > >> douailleerwan@ > >> > wrote: >> >>> https://ci.inria.fr/pharo-contribution/job/SourceCity/ >>> >>> done >>> >>> >>> 2013/7/4 Camillo Bruni < > >> camillobruni@ > >> > >>> >>> On 2013-07-04, at 15:35, Erwan Douaille < > >> douailleerwan@ > >> > wrote: >>> >>>> I updated the ConfigurationOfSourceCity. >>>> >>>> Gofer new >>>> smalltalkhubUser: 'ErwanDouaille' project: 'SourceCity'; >>>> configuration; >>>> load. >>>> ConfigurationOfSourceCity loadBleedingEdge >>> >>> would it make sense to make a jenkins job for this? >>> >>> >>> >>> >>> -- >>> Best regards, >>> >>> Douaille Erwan < > >> douaille.erwan@ > >> > >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > -- > View this message in context: http://forum.world.st/Pharo-dev-OpenGL-NBMacGlAPI-missing-tp4692287p4697523… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 5, 2013

Re: [Pharo-dev] NativeBoost with no access to sources

by Goubier Thierry

Le 05/07/2013 15:31, Igor Stasenko a Ã©crit : > On 5 July 2013 15:22, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 5 July 2013 11:03, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>> Could you rather test for unability to get the source of the method and >>> raise a NB-defined error? So that I could write a fallback on non-NB code >>> with a on: do:. Please :) >>> >>> (it would then both handle startup related errors and unreadable sources as >>> well). >>> >>> And with a backport to 2.0, because the odds of seeing an Opal based >>> solution on 2.0 are fairly low. >>> >> the problem is that you will get same error when you put wrong name >> into signature >> or when no sources avail e.g.: >> >> foo: bar >> ^ self nbCall: #( void foo (int baz) ) >> >> will give same error (unable to find binding for name 'baz' in given context). Of course. I could do with having the same error for both and knowing that when developping and testing I would get it for stupid syntax errors and in production to handle a real situation. >> If its fine to you, i can do it. Maybe I can try myself to see if I can write, before entering that loader stuff, a correct test which raises an error if the method source isn't available. >>> >>> Is there a real, practical difference between "at compilation time" and >>> "when receiving MethodAdded event"? i.e. is the complexity added in the >>> compilation process worthwhile? >>> >> the problem is that you may not always receive MethodAdded event, >> because different tools putting different meaning into "this should be >> compiled silently". >> This is outstanding issue in Pharo.. and that's the main reason why i >> would go with compiler (like >> that i have guarantee that instance of CompiledMethod is well-formed, >> and don't need to rely on >> 3-rd party toolchain to deliver notification to me. You mean that hacking support into the third party compiler isn't 3rd party toolchain :) >> and besides, we need such hook mechanism in Compiler anyways (for many >> other use cases) >> and so, it will be not "renting a Boeing for single passenger" >> > > oh.. and i forgot about most important aspect of it: > i don't wanna see > <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: > errorCode > > in code, instead if wanna use > > <native> > (or similar), > which admit, much more concise, elegant and user-friendly, and hides > unnecessary implementation detail. I remember seeing people introducing syntax extensions inside smalltalk methods in VisualWorks, would that work as well ? Customize on a per class / per method which compiler we should use. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

July 5, 2013

Re: [Pharo-dev] [Issue tracker] Please have a look at your issues!

by Goubier Thierry

Thanks Marcus for all that! Thierry Le 05/07/2013 15:10, Marcus Denker a Ã©crit : > > On Jul 5, 2013, at 1:14 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> >> >> Le 05/07/2013 09:00, Marcus Denker a Ã©crit : >>> >>> https://pharo.fogbugz.com/f/filters/8/2-0-Work-Needed >> >> All the 2.0 backports I have been looking at have fixes waiting for review... I'm using the fixes on a daily basis (loading by hand the relevant SLICES). > > Yes, it would be nice if someone would look at them. > >> >>> and 3.0: >>> >>> https://pharo.fogbugz.com/f/filters/37/3-0-Work-Needed >> >> For those I'm involved in, I don't have access rights to upload SLICES, so I have stored them under http://smalltalkhub.com/mc/ThierryGoubier/Alt30/main. >> (loading by hand the slices, otherwise 3.0 does not even work at all for me). >> > > I > -> copied them over > -> added a not to the bug entries > -> put those to "review needed" > -> Added you to the Pharo team so you can commit directly > (it is on the TODO so that there is an inbox where everyone can commit > > > Marcus > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

July 5, 2013

NativeBoost and lacking string argument/return handling

by Henrik Johansen

I just had a glance at Nix/Win32Environment NB calls, and nearly cried... (context: http://www.youtube.com/watch?v=Um41DPPs5ZA&list=SP843D1D545F9F52B6&index=15… ) Which got me thinking, maybe an extra opt (possibly non-static, ref database libraries string encodings) if Strings are expected as parameters should be mandatory, for specifying the expected encoding of the library being called? (oh yes, MANDATORY, if you don't know what is required, you shouldn't be passing in Smalltalk strings in the first place) You'd then be able to cut out ALL the manual cruft in the video's getEnvironmentVariableW: wrapper call basically needed for any current call to a method accepting Strings. (assuming you're not ok with mysterious failures once parameter/return is outside ascii range) Might it work with a few choice assembly implementations of encoders (utf8 + utf16) along the lines of NBUTF8StringExample (expanded to handle both Wide- and ByteString arguments/returns), as well as a fallback (or just) using callback which employs in-image converters? (Such a preamble would also be a good place to do embedded 0 character checks for args expected to be c strings: http://www.hakipedia.com/index.php/Poison_Null_Byte) This have some other implications as well of course; -NBExternalAddress readString/writeString should be removed or made encoding aware. In the current form, they are dangerous/useless outside of pure asciiâ¦ - How to handle char * parameters. Perhaps parameter-specific validity checks? a) NBExternalAddress - Assume correctly manually encoded contents if allowExternalAddressOpt or whatever its called is set? b) ByteArray - Assume correctly manually encoded contents? c) String - Same as above, either encoding opt set, or return error Cheers, Henry

July 5, 2013

Re: [Pharo-dev] NativeBoost with no access to sources

by Igor Stasenko

On 5 July 2013 15:22, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 5 July 2013 11:03, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> >> >> Le 04/07/2013 19:11, Igor Stasenko a Ã©crit : >>> >>> On 4 July 2013 13:07, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>>> >>>> >>>> >>>> >>>> I wondered if it could be both (name and number), but went for the >>>> shortest >>>> path, that is the simplest solution: >>>> >>>> NBFFICallout>>loaderFromMethodArgsNamed: argName >>>> >>>> methodArgs >>>> ifNotNil: [ >>>> | index | >>>> (argName first = $_ and: [ argName allButFirst >>>> isAllDigits ]) >>>> ifTrue: [ ^ NBSTMethodArgument new >>>> stackIndex: methodArgs size - argName asUnsignedInteger ]. >>>> index := methodArgs indexOf: argName ifAbsent: [ >>>> nil >>>> ]. >>>> index >>>> ifNotNil: [ >>>> "ok, this is a method argument" >>>> ^ NBSTMethodArgument new >>>> stackIndex: >>>> methodArgs size - index ] ]. >>>> ^ nil >>>> >>> This looks fine , and i will add it into NB. >> >> >> Could you rather test for unability to get the source of the method and >> raise a NB-defined error? So that I could write a fallback on non-NB code >> with a on: do:. Please :) >> >> (it would then both handle startup related errors and unreadable sources as >> well). >> >> And with a backport to 2.0, because the odds of seeing an Opal based >> solution on 2.0 are fairly low. >> > the problem is that you will get same error when you put wrong name > into signature > or when no sources avail e.g.: > > foo: bar > ^ self nbCall: #( void foo (int baz) ) > > will give same error (unable to find binding for name 'baz' in given context). > > If its fine to you, i can do it. > > >> >>>> Then I tried to change all calls to use numbers, but it ended in a >>>> Segfault >>>> (not in NB itself, but somewhere else as if I had a corrupted heap). The >>>> end >>>> result with all changes is there: >>>> >>> >>>> >>>> http://ss3.gemstone.com/ss/PharoInbox/SLICE-Issue-11102-FileSystemError-Pat… >>>> >>>> If you see where I missed something, I'd be happy to know. >>>> >>> >>> you probably made a mistake somewhere. ;) >>> because counting the argument index, instead of putting its name is >>> error prone. >> >> >> Well, in almost all cases, arguments were used in the order they were given, >> which should have been almost foolproof ;) >> > that's why there is separate words in english for 'all' and 'almost' :) > >> >>> not cache, just put it into method's attributes, so i can access them >>> later. >>> And not when method added/removed, but at compilation time. >> >> >> Is there a real, practical difference between "at compilation time" and >> "when receiving MethodAdded event"? i.e. is the complexity added in the >> compilation process worthwhile? >> > the problem is that you may not always receive MethodAdded event, > because different tools putting different meaning into "this should be > compiled silently". > This is outstanding issue in Pharo.. and that's the main reason why i > would go with compiler (like > that i have guarantee that instance of CompiledMethod is well-formed, > and don't need to rely on > 3-rd party toolchain to deliver notification to me. > > and besides, we need such hook mechanism in Compiler anyways (for many > other use cases) > and so, it will be not "renting a Boeing for single passenger" > oh.. and i forgot about most important aspect of it: i don't wanna see <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > in code, instead if wanna use <native> (or similar), which admit, much more concise, elegant and user-friendly, and hides unnecessary implementation detail. >> Thierry >> >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> > > > > -- > Best regards, > Igor Stasenko. -- Best regards, Igor Stasenko.

July 5, 2013

Re: [Pharo-dev] NativeBoost with no access to sources

by Igor Stasenko

On 5 July 2013 11:03, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 04/07/2013 19:11, Igor Stasenko a Ã©crit : >> >> On 4 July 2013 13:07, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>> >>> >>> >>> >>> I wondered if it could be both (name and number), but went for the >>> shortest >>> path, that is the simplest solution: >>> >>> NBFFICallout>>loaderFromMethodArgsNamed: argName >>> >>> methodArgs >>> ifNotNil: [ >>> | index | >>> (argName first = $_ and: [ argName allButFirst >>> isAllDigits ]) >>> ifTrue: [ ^ NBSTMethodArgument new >>> stackIndex: methodArgs size - argName asUnsignedInteger ]. >>> index := methodArgs indexOf: argName ifAbsent: [ >>> nil >>> ]. >>> index >>> ifNotNil: [ >>> "ok, this is a method argument" >>> ^ NBSTMethodArgument new >>> stackIndex: >>> methodArgs size - index ] ]. >>> ^ nil >>> >> This looks fine , and i will add it into NB. > > > Could you rather test for unability to get the source of the method and > raise a NB-defined error? So that I could write a fallback on non-NB code > with a on: do:. Please :) > > (it would then both handle startup related errors and unreadable sources as > well). > > And with a backport to 2.0, because the odds of seeing an Opal based > solution on 2.0 are fairly low. > the problem is that you will get same error when you put wrong name into signature or when no sources avail e.g.: foo: bar ^ self nbCall: #( void foo (int baz) ) will give same error (unable to find binding for name 'baz' in given context). If its fine to you, i can do it. > >>> Then I tried to change all calls to use numbers, but it ended in a >>> Segfault >>> (not in NB itself, but somewhere else as if I had a corrupted heap). The >>> end >>> result with all changes is there: >>> >> >>> >>> http://ss3.gemstone.com/ss/PharoInbox/SLICE-Issue-11102-FileSystemError-Pat… >>> >>> If you see where I missed something, I'd be happy to know. >>> >> >> you probably made a mistake somewhere. ;) >> because counting the argument index, instead of putting its name is >> error prone. > > > Well, in almost all cases, arguments were used in the order they were given, > which should have been almost foolproof ;) > that's why there is separate words in english for 'all' and 'almost' :) > >> not cache, just put it into method's attributes, so i can access them >> later. >> And not when method added/removed, but at compilation time. > > > Is there a real, practical difference between "at compilation time" and > "when receiving MethodAdded event"? i.e. is the complexity added in the > compilation process worthwhile? > the problem is that you may not always receive MethodAdded event, because different tools putting different meaning into "this should be compiled silently". This is outstanding issue in Pharo.. and that's the main reason why i would go with compiler (like that i have guarantee that instance of CompiledMethod is well-formed, and don't need to rely on 3-rd party toolchain to deliver notification to me. and besides, we need such hook mechanism in Compiler anyways (for many other use cases) and so, it will be not "renting a Boeing for single passenger" > Thierry > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > -- Best regards, Igor Stasenko.

July 5, 2013

Re: [Pharo-dev] [Issue tracker] Please have a look at your issues!

by Marcus Denker

On Jul 5, 2013, at 1:14 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 05/07/2013 09:00, Marcus Denker a Ã©crit : >> >> https://pharo.fogbugz.com/f/filters/8/2-0-Work-Needed > > All the 2.0 backports I have been looking at have fixes waiting for review... I'm using the fixes on a daily basis (loading by hand the relevant SLICES). Yes, it would be nice if someone would look at them. > >> and 3.0: >> >> https://pharo.fogbugz.com/f/filters/37/3-0-Work-Needed > > For those I'm involved in, I don't have access rights to upload SLICES, so I have stored them under http://smalltalkhub.com/mc/ThierryGoubier/Alt30/main. > (loading by hand the slices, otherwise 3.0 does not even work at all for me). > I -> copied them over -> added a not to the bug entries -> put those to "review needed" -> Added you to the Pharo team so you can commit directly (it is on the TODO so that there is an inbox where everyone can commit Marcus

July 5, 2013

Re: [Pharo-dev] [Issue tracker] Please have a look at your issues!

by Goubier Thierry

Le 05/07/2013 09:00, Marcus Denker a Ã©crit : > Hi, > > We should do a pass over all issues. > > e.g. > -> is your bug still relevant? > -> if you submitted a fix, maybe the bug status is wrong and therefore nobody looked at it? > -> if you added a verbal description of how to fix something, consider submitting code in addition > (people have just no idea how much easier it is to deal with machine readable code than half-a-page of proseâ¦) > -> You where involved in a discussion about a bug. So now go trough it and summarize: What is the next *action* > that needs to be done to close the issue? > > You can get a list of *all* open issues: > > https://pharo.fogbugz.com/f/filters/33/All-Opened > > or just the ones for 2.0: > > https://pharo.fogbugz.com/f/filters/8/2-0-Work-Needed All the 2.0 backports I have been looking at have fixes waiting for review... I'm using the fixes on a daily basis (loading by hand the relevant SLICES). > and 3.0: > > https://pharo.fogbugz.com/f/filters/37/3-0-Work-Needed For those I'm involved in, I don't have access rights to upload SLICES, so I have stored them under http://smalltalkhub.com/mc/ThierryGoubier/Alt30/main. (loading by hand the slices, otherwise 3.0 does not even work at all for me). Thierry > > For the 2.0/3.0 issues, we should decide: are they really of a kind that they need to fixed before we > can release? (in 2.0: do we really need to back port? or is it enough to fix in 3.0?) > > Marcus > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

July 5, 2013