- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] WhatsUp from: 2013-07-01 until: 2013-07-14

by Damien Cassou

On Mon, Jul 1, 2013 at 7:00 AM, <seaside(a)rmod.lille.inria.fr> wrote: > ### Here's what I've been up to since the last WhatsUp: > prepare and give Pharo tutorial at ECOOP, Montpellier, France prepare a Pharo cheat sheet flyer with Damien Pollet and Vincent Blondeau Pharo launcher: improve code, add tests, and some features Review many bugs and fixes some Rewrite all user-directory logic (home, desktop, documents, preferences) to use environment variables (linux, macosx, windows) Worked with Sebastian on trait-related code (bug fixing mostly) update pharo vm for ubuntu > ### What's next, until 2013-07-14 (*): > release the first version of Pharo Launcher -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

July 5, 2013

Re: [Pharo-dev] Visual element - Pogress bar.

by Mariano Vicente

Yes is just exactly I was searching for. thanks Ben. âRegards, Mariano On Fri, Jul 5, 2013 at 7:13 AM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Just that you know, by opening the example, the slider is far too big. > > If you set its size properly, it will look like your screenshot (more or > less ^^) > > Ben > > On Jul 5, 2013, at 12:03 PM, Mariano Vicente <m.vicent(a)gmail.com> wrote: > > In the screenshot don't look like as a progress bar. > â â > How can use it? I write in the workspace and is unknow. > Should download some package? > â â > (I'm using pharo 3.0) > > âRegards, > Mariano > > > On Fri, Jul 5, 2013 at 6:51 AM, Benjamin < > benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> Is a SlideMorph what you are looking for ? >> >> <Screen Shot 2013-07-05 at 11.51.04 AM.png> >> Ben >> >> On Jul 5, 2013, at 11:36 AM, Mariano Vicente <m.vicent(a)gmail.com> wrote: >> >> Hello >> I'm searching for a visual component such as >> â video â >> progress bar >> â / seek bar or something like this: >> [image: Inline image 1] >> >> are there something like it ? >> >> âRegards, >> Mariano >> >> >> > >

July 5, 2013

Re: [Pharo-dev] Roassal 3d is on its way

by Alexandre Bergel

Yes, the RMoD crew did an amazing job! Alexandre Le 05-07-2013 Ã 7:01, kilon <thekilon(a)yahoo.co.uk> a Ã©crit : > Looks like NBOpenGL opened the door to many graphics projects , including > mine, these are truly fascinating times for pharo and would love to take a > look at Roassal 3d when it is released. Keep up the great work ;) > > > > -- > View this message in context: http://forum.world.st/Pharo-dev-Roassal-3d-is-on-its-way-tp4697319p4697525.… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

July 5, 2013

Re: [Pharo-dev] NativeBoost and lacking string argument/return handling

by Henrik Sperre Johansen

Was leaving work in a hurry there, think I forgot a not and some smileys in the last post ;) Anyways, in combination with an encoding opt, a nice addition (for those functions expecting size of string as separate parameter) would be being able to specify strLength(myString) as the size parameter, and have it computed after conversion, otherwise you still have to do it all in an image-side wrapper to get the correct number... 2 weeks vacation upcoming, I guess I got plans if the weather is bad ;) Cheers, Henry

July 5, 2013

Re: [Pharo-dev] NativeBoost and lacking string argument/return handling

by Henrik Johansen

On Jul 5, 2013, at 4:59 , Igor Stasenko wrote: > Well, to my thinking , in C 'string' defined as 'a sequence of > characters (bytes) terminated by zero byte'. Yeah, except, you know, most/all libraries do not really deal with theoretically pure C strings, and we certainly when passing in "a string" from Smalltalk. In practice, we're dealing with passing/converting Smalltalk strings to functions expecting a pointer to bytes in a certain encoding. (either null-terminated or with an additional size arg) > There is nothing about encoding, because it is related to text, but C > 'string' can be something else than human-readable text and contain > anything and used for different purpose. > > From that perspective, if strictly following such definition, i do not > see how you can force encoding to be a mandatory part of it. (except > from having special encoding, named "NO_ENCODING" ;) And from that perspective, any user will *never* create safe bindings to/from anything but ASCII ByteStrings by default. FFI, meet 1988. And even those who do, have to jump through an excessive amount of hoops, ref https://dl.dropboxusercontent.com/u/6751081/Environment.zip > > But sure thing, i am not opposed to having a really nice > encoding/decoding schemes, which you can easily control. > > The caveat is that options is applicable to whole callout's generated code. > What if i have function which takes 2 arguments: > - string with utf-8 encoding > - string with utf-16 encoding > > so, you cannot put that in options, because you need to control it on > a per-argument basis. > > The only way i see how to do that is same as in NBUTF8StringExample: > you explicitly designate the type of argument e.g. > > void foo(utf8String x, utf16String y) No, not for FFI you don't. Any sane external library will never use different encodings for string parameters to the same method. In fact, I challenge you to find *any* which doesn't. Cheers, Henry

July 5, 2013

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

by Igor Stasenko

Here is another quick and dirty recipe 4U: - make a extension method in CompiledMethod nbEnsureTempNames self propertyValueAt: #tempNames ifAbsent: [ self propertyValueAt: #tempNames put: self tempNames ] nbTempNames ^ self propertyValueAt: #tempNames NativeBoost class>>prepareForProduction CompiledMethod allInstancesDo: [:aMethod | ((aMethod primitive = 117) and: [ | lit | lit := aMethod literalAt: 1. lit first = #NativeBoostPlugin and: [ lit second == #primitiveNativeCall]]) ifTrue: [ aMethod nbEnsureTempNames ]. ] (and then sure thing, make sure to use #nbTempNames instead of tempNames). but for the future, i want a clear protocol in CompiledMethod to do that, and do not make it depend on system changes. Because if i do, the stuff which works in 2.0 (or 3.0) will suddenly stop working in next version, because of changes in system.. that's why i against even thinking that NB having something to do with method's source code. It needs method's argument names, and nothing else, period. -- Best regards, Igor Stasenko.

July 5, 2013

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

by Igor Stasenko

On 5 July 2013 16:55, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 05/07/2013 16:36, Igor Stasenko a Ã©crit : > >> 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? > > > I believe the proper way would be to have : > > NBCannotBindName (for the errors you already handle at the moment) > > and, somewhere in there, a > > NBMethodSourceNotAvailable > > triggered in NBFFICallout>>sender: if the source code is decompiledCode > (but, as far as I can see, there is no method to test a CompiledMethod for > that :)) > > Something like > > CompiledMethod>>hasSourceCode > "Say false if we have to reconstruct the code." > > | trailer source | > trailer := self trailer. > trailer sourceCode > ifNotNil: [:code | ^ true ]. > trailer hasSourcePointer > ifFalse: [ ^ false]. > "Situation normal; read the sourceCode from the file" > source := [self getSourceFromFile] > on: Error > do: [ :ex | ex return: nil]. > source isEmptyOrNil > ifTrue: [ ^ false ]. > ^ true > > and, in sender: > > aSenderContext method hasSourceCode > ifFalse: [NBMethodSourceNotAvailable signal: method printString] > > What do you think ? > I think it is not responsibility of NB to deal with availability of source code. NB simply using reflection protocol of system to get what it wants to get, and where it come (from source code, or from something else) is completely irrelevant. Yes, with current implementation, it ends up with getting & parsing source code, but it is not what NB is asking for: the intent is to simply ask a compiled method to provide the argument names. That's why i totally agree with introduction of NBCannotBindName exception, but i cannot see place for NBMethodSourceNotAvailable. Otherwise similar tools with similar requirements will need to (re)implement same? This should be a responsibility of kernel/system.. but not NB itself. > > 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] NativeBoost and lacking string argument/return handling

by Igor Stasenko

Well, to my thinking , in C 'string' defined as 'a sequence of characters (bytes) terminated by zero byte'. There is nothing about encoding, because it is related to text, but C 'string' can be something else than human-readable text and contain anything and used for different purpose. >From that perspective, if strictly following such definition, i do not see how you can force encoding to be a mandatory part of it. (except from having special encoding, named "NO_ENCODING" ;) But sure thing, i am not opposed to having a really nice encoding/decoding schemes, which you can easily control. On 5 July 2013 15:45, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > 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 > The caveat is that options is applicable to whole callout's generated code. What if i have function which takes 2 arguments: - string with utf-8 encoding - string with utf-16 encoding so, you cannot put that in options, because you need to control it on a per-argument basis. The only way i see how to do that is same as in NBUTF8StringExample: you explicitly designate the type of argument e.g. void foo(utf8String x, utf16String y) > Cheers, > Henry > > -- Best regards, Igor Stasenko.

July 5, 2013

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

by Goubier Thierry

Le 05/07/2013 16:36, Igor Stasenko a Ã©crit : > 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? I believe the proper way would be to have : NBCannotBindName (for the errors you already handle at the moment) and, somewhere in there, a NBMethodSourceNotAvailable triggered in NBFFICallout>>sender: if the source code is decompiledCode (but, as far as I can see, there is no method to test a CompiledMethod for that :)) Something like CompiledMethod>>hasSourceCode "Say false if we have to reconstruct the code." | trailer source | trailer := self trailer. trailer sourceCode ifNotNil: [:code | ^ true ]. trailer hasSourcePointer ifFalse: [ ^ false]. "Situation normal; read the sourceCode from the file" source := [self getSourceFromFile] on: Error do: [ :ex | ex return: nil]. source isEmptyOrNil ifTrue: [ ^ false ]. ^ true and, in sender: aSenderContext method hasSourceCode ifFalse: [NBMethodSourceNotAvailable signal: method printString] What do you think ? 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

[update 3.0] #30257/#30258

by Marcus Denker

30257/30258 ----- 11143 Update Opal to latest version https://pharo.fogbugz.com/f/cases/11143 11095 Array >> #elementsForwardIdentityTo:copyHash: More explicit tests and comments https://pharo.fogbugz.com/f/cases/11095 11007 Pharo 3 now uses mustBeBooleanInMagic: by default https://pharo.fogbugz.com/f/cases/11007 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tests-MarcusDenker.569.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Tests-MarcusDenk… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1513.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Sequenceable-Marc…

July 5, 2013