January 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] 17348 Enhance shortcut learnability

by Henrik Nergaard

Hi Stef, Something like this? (see attachment) Best regards, Henrik From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of stepharo Sent: Monday, January 11, 2016 4:52 PM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] 17348 Enhance shortcut learnability Henrik Thanks. What I would love to get is another little morph below the shortcut with the name of the menu like that we can learn that the tools xxx is launched with shortcut cmd X I think that we should have a preference that does not flush the counters at startup Stef Le 11/1/16 12:14, Henrik Nergaard a Ã©crit : Somehow it integrated ______________ Name: SLICE-Issue-17348-Enhance-shortcut-learnability-tr.2 Author: tr Time: 8 January 2016, 4:18:55.135106 pm UUID: 0aa30f76-84f3-0449-acde-172e56ea3615 Ancestors: SLICE-Issue-17348-Enhance-shortcut-learnability-tr.1 Dependencies: Morphic-Base-tr.526 better version instead of: ____________ Name: SLICE-Issue-17348-Enhance-shortcut-learnability-HenrikNergaard.2 Author: HenrikNergaard Time: 8 January 2016, 11:01:18.490743 pm UUID: 2a6f1c3f-a0b3-524d-9095-02fb42ab8358 Ancestors: SLICE-Issue-17348-Enhance-shortcut-learnability-tr.1 Dependencies: Morphic-Base-HenrikNergaard.526 Refactor of initial code. I have updated and merged a new slice (in Image 50521) which should fix it. The correct version that should be integrated is: Name: SLICE-Issue-17348-Enhance-shortcut-learnability-HenrikNergaard.5 Author: HenrikNergaard Time: 11 January 2016, 12:17:08.504781 am UUID: f0271c17-07a7-0d4e-a6eb-d2fef9b2853c Ancestors: SLICE-Issue-17348-Enhance-shortcut-learnability-HenrikNergaard.4 Dependencies: Morphic-Base-HenrikNergaard.530 remove unused variable. Best regards, Henrik From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Marcus Denker Sent: Monday, January 11, 2016 11:35 AM To: Pharo Development List <pharo-dev(a)lists.pharo.org><mailto:pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] 17348 Enhance shortcut learnability Hello, I wil reopen the issue and put your comment there. Marcus On 11 Jan 2016, at 09:56, Nicolai Hess <nicolaihess(a)gmail.com<mailto:nicolaihess@gmail.com>> wrote: Can please someone translate / change the text in the Shortcut reminder Morph settings.( that got integrated in 50521) see my comment on https://pharo.fogbugz.com/f/cases/17348/Enhance-shortcut-learnability#BugEv… and I asked for resubmitting the changes with proper author initials instead of "tr" and if he signed the license agreement. Anyone knows more about "tr" ? And I am not sure if the right version is integrated. nicolai

Jan. 12, 2016

Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI

by Esteban A. Maringolo

2016-01-12 16:49 GMT-03:00 stepharo <stepharo(a)free.fr>: > > > Le 12/1/16 17:58, Denis Kudriashov a Ã©crit : > > Hi > > UFFI reminds me UFO which can be translated like Unified Foreign Objects. > And it has some relation to Alien name. > But maybe it is too much funny name > > > Quite cool :) > +1 UFFI is concise too. Esteban A. Maringolo

Jan. 12, 2016

Re: [Pharo-dev] Bad layoutFrame>>#hash

by stepharo

Hi david I rad the wikipedia page you mention and this looks a bit obvious to me. I knew this. now it does not really help fixing the problem you mention. Stef Le 11/1/16 10:09, David Allouche a Ã©crit : > Since it's not obvious why xor-ing is a bad way to produce hash, here is a link that gives some background > > https://en.wikipedia.org/wiki/Hash_function#Uniformity > >> On 11 Jan 2016, at 10:01, David Allouche <david(a)allouche.net> wrote: >> >> I happened to look at the new code for LayoutFrame>>#hash >> >> hash >> ^self species hash bitXor: >> (self leftFraction bitXor: >> (self leftOffset bitXor: >> (self topFraction bitXor: >> (self topOffset bitXor: >> (self rightFraction bitXor: >> (self rightOffset bitXor: >> (self bottomFraction bitXor: >> self bottomOffset))))))) >> >> This is a terrible, terrible way to compute a hash. >> >> 0 xor 0 = 1 xor 1 = 2 xor 2 = etc. >> >> NEVER compute hashes with xor, that's wrong, and it causes horrible, hard to debug, performance bugs down the road. >> >> SequenceableCollection>>#hash looks more like a correct way of doing it. I do not know what is the correct, efficient way to reuse this logic in LayoutFrame>>#hash. >> >> By the way, how do you guys do code reviews for code integrated into the core? >> > >

Jan. 12, 2016

Re: [Pharo-dev] [Vm-dev] [squeak-dev] valid pragma syntax

by Esteban Lorenzano

wellâ¦ UnifiedFFI, UFFI or whatever it will be called already does thatâ¦ as you know. Currently we are using âolderâ NB way: as a method call, then solving it in first call. This is nice because is compatible and easies some stuff. But final objective is to provide a pragma and solve it in compilation time. Then we can 100% deprecate the invalid pragma old FFI uses today. At least, thatâs what we have talk :) Esteban > On 12 Jan 2016, at 20:06, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-01-10 16:57 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>>: > > Hi Nicolai, > > On Sun, Jan 10, 2016 at 3:16 AM, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: > pharo fogbugz issue: 17359 MessageNotUnderstood: receiver of "keywords" is nil > > > is this valid pragma syntax: > > <apicall: bool 'SetCursorPos' (long long) module: 'user32.dll'> > > As others have said this is not a valid pragma. A valid pragma is a message expression (a message with no receiver) that has only literal arguments. There is one exception, to accept a variable name for the error code in a primitive invocation. > > And as Levente has said it is a goal of the new FFI to get rid of the old syntax you show above. > > > Thanks Eliot. > > I think I will wait what Esteban will say to this, he put those classes in the image, maybe he had a plan for the new ffi/apicall syntax > > > > And as Igor Stasenko discovered /any/ C signature can be written as a literal Array, providing we allow underscores in Symbols (which is a preference). So for example, the heapsort declaration from the standard C library: > > int > heapsort(void *base, size_t nel, size_t width, > int (*compar)(const void *, const void *)) > > could be written as a pragma via e.g. > > <ffiCCall: #(int heapsort(void *base, size_t nel, size_t width, int (*compar)(const void *, const void *)))> > > in which case it is equal to > > <ffiCCall: #(#int #heapsort #( #void #* #base #, #size_t #nel #, #size_t #width #, #int #( #* #compar ) #( #const #void #*, #const #void #*)))> > > which, while a massive hack, is pretty neat. The only difficulty in parsing the above s that void *, is #void #*, not #void #* #,. > > So for me, the natural pragma syntax for the new FFI should be a single keyword starting with ffi that includes the language with which to parse the pragma's argument, followed by a literal Array containing the signature (rather than e.g. a String). I'd also provide a special-purpose pretty-printer for literal arrays that would be used to pretty-print the above, e.g. when decompiling. > > This would easily allow extensions such as > > <ffiCcall: #(wchar_t * wcschr(const wchar_t *s, wchar_t c)) arg1is: #UnicodeString arg2is: Character> > > to guide a marshalling engine in providing automatic checks and conversions. > > [Slightly OT] > Note that I'm already using this syntax in Alien callbacks because one thing it does is to normalize the signature, eliminating the significance of most whitespace (the #*, above being one example where it fails). So a Callback for heapsort above looks like > > voidstarvoidstarRetint: callbackContext sp: spAlien > <signature: #(int (*)(const void *, const void *)) abi: #IA32> > ^callbackContext wordResult: > (block > value: (Alien forPointer: (spAlien unsignedLongAt: 1)) > value: (Alien forPointer: (spAlien unsignedLongAt: 5))) > > or > voidstarvoidstarRetintARM32: callbackContext sp: spAlien > <signature: #(int (*)(const void *, const void *)) abi: #ARM32> > ^callbackContext wordResult: > (block > value: (Alien forPointer: (spAlien registerAt: 1)) > value: (Alien forPointer: (spAlien registerAt: 2))) > > > Hmmm, if Callback had subclasses for each ABI then the above would become > > IA32Callback methods for signature > voidstarvoidstarRetint: callbackContext sp: spAlien > <signature: #(int (*)(const void *, const void *))> > ^callbackContext wordResult: > (block > value: (Alien forPointer: (spAlien unsignedLongAt: 1)) > value: (Alien forPointer: (spAlien unsignedLongAt: 5))) > > ARM32Callback methods for signatures > voidstarvoidstarRetint: callbackContext sp: spAlien > <signature: #(int (*)(const void *, const void *))> > ^callbackContext wordResult: > (block > value: (Alien forPointer: (spAlien registerAt: 1)) > value: (Alien forPointer: (spAlien registerAt: 2))) > > Much nicer. I shall make it so. > > our (pharo) parser can not parse this (does not recognizes the > "selector parts" (apicall:module:) right) > > Any recommendations how to fix this > - fix RBParser or > - change this pragma, for example, like this > <apicall: #(bool SetCursorPos (long long)) module: 'user32.dll'> > > > nicolai > > _,,,^..^,,,_ > best, Eliot > >

Jan. 12, 2016

Re: [Pharo-dev] Bad layoutFrame>>#hash

by stepharo

Ok but be concrete. What will be the solution for this particular case? Stef Le 11/1/16 22:30, Nicolas Cellier a Ã©crit : > Yep, a must read if you want to improve the hash methods. > > 2016-01-11 10:09 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu > <mailto:sven@stfx.eu>>: > > David, > > > On 11 Jan 2016, at 10:01, David Allouche <david(a)allouche.net > <mailto:david@allouche.net>> wrote: > > > > I happened to look at the new code for LayoutFrame>>#hash > > > > hash > > ^self species hash bitXor: > > (self leftFraction bitXor: > > (self leftOffset bitXor: > > (self topFraction bitXor: > > (self topOffset bitXor: > > (self rightFraction bitXor: > > (self rightOffset bitXor: > > (self bottomFraction bitXor: > > self bottomOffset))))))) > > > > This is a terrible, terrible way to compute a hash. > > > > 0 xor 0 = 1 xor 1 = 2 xor 2 = etc. > > > > NEVER compute hashes with xor, that's wrong, and it causes > horrible, hard to debug, performance bugs down the road. > > Yeah, that doesn't look very good ;-) > > > SequenceableCollection>>#hash looks more like a correct way of > doing it. I do not know what is the correct, efficient way to > reuse this logic in LayoutFrame>>#hash. > > There is actually a 2 part book just about hashing in Smalltalk: > > http://www.lulu.com/shop/andres-valloud/hashing-in-smalltalk-theory-and-pra… > > It is said to be very good, I sadly have not yet read it ;-) > > > By the way, how do you guys do code reviews for code integrated > into the core? > > 'Pharo is yours' which means: if you encounter something odd, you > are encouraged to improve it. Maybe first discuss it on the ML. If > necessary create an issue. Better provide a fix. > > Sven > > > > >

Jan. 12, 2016

Re: [Pharo-dev] Bad layoutFrame>>#hash

by stepharo

You see K. Beck in his book smalltalk best pratices promotes this form. So can you propose a better solution so that we learn? Stef Le 11/1/16 10:09, David Allouche a Ã©crit : > Since it's not obvious why xor-ing is a bad way to produce hash, here is a link that gives some background > > https://en.wikipedia.org/wiki/Hash_function#Uniformity > >> On 11 Jan 2016, at 10:01, David Allouche <david(a)allouche.net> wrote: >> >> I happened to look at the new code for LayoutFrame>>#hash >> >> hash >> ^self species hash bitXor: >> (self leftFraction bitXor: >> (self leftOffset bitXor: >> (self topFraction bitXor: >> (self topOffset bitXor: >> (self rightFraction bitXor: >> (self rightOffset bitXor: >> (self bottomFraction bitXor: >> self bottomOffset))))))) >> >> This is a terrible, terrible way to compute a hash. >> >> 0 xor 0 = 1 xor 1 = 2 xor 2 = etc. >> >> NEVER compute hashes with xor, that's wrong, and it causes horrible, hard to debug, performance bugs down the road. >> >> SequenceableCollection>>#hash looks more like a correct way of doing it. I do not know what is the correct, efficient way to reuse this logic in LayoutFrame>>#hash. >> >> By the way, how do you guys do code reviews for code integrated into the core? >> > >

Jan. 12, 2016

Re: [Pharo-dev] ifError: implementation is bad

by stepharo

+1111^1111111 > > We should make a list. Some that should be easy: > > - Delay should be splitted why? > - Chronology should be splitted > > One more complicated: > > - InstructionClient and InstructionStream should be splitted > > And then, we should also review the API of basic objects > > Object methods size => 385 > Integer methods size => 182 > ...

Jan. 12, 2016

Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI

by Dimitris Chloupis

Ah I forgot the name UFFI is also used by the Common Lisp http://www.cliki.net/UFFI On Tue, Jan 12, 2016 at 9:50 PM stepharo <stepharo(a)free.fr> wrote: > > > Le 12/1/16 17:58, Denis Kudriashov a Ã©crit : > > Hi > > UFFI reminds me UFO which can be translated like Unified Foreign Objects. > And it has some relation to Alien name. > But maybe it is too much funny name > > > Quite cool :) > > Stef > > > > 2016-01-12 16:55 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> Hi, >> >> People has pointed (and they are right) that the name of the new FFI >> front-end is misleading. >> So yesterday I was talking with Stef and we think UnifiedFFI (or UFFI, >> for short) is a better nameâ¦ and to keep packages prox. to regular FFI I >> was thinking on rename FFI-NB packages to FFI-Unifiedâ¦ but maybe is better >> just to rename them as UFFI or UnifiedFFIâ¦ >> what do you think? >> >> Esteban >> >> >> > >

Jan. 12, 2016

Re: [Pharo-dev] How to get launcher launching Spur images?

by stepharo

ok I will retry. Le 12/1/16 15:23, Ben Coman a Ã©crit : > On Tue, Jan 12, 2016 at 10:03 PM, stepharo <stepharo(a)free.fr> wrote: >> I loaded the stable version in Pharo 50 and I saw that it does not have the >> Spur special Folder. >> So I loaded the latest version of the packages from the repo and I could not >> run the launcher anymore. >> >> So could you tell me how you did it? > Err, umm... looking just now I see only one settable VM path. So it > seems I did not load the latest, only the version from the Catalog. > So I guess I can only run Spur images. > > cheers -ben > >> Stef >> >> Le 11/1/16 16:48, stepharo a Ã©crit : >> >> Ok I will do the same then ;) >> >> >> Le 11/1/16 13:09, Ben Coman a Ã©crit : >> >> >> On Mon, Jan 11, 2016 at 1:49 AM, stepharo <stepharo(a)free.fr> wrote: >>> Hi >>> >>> I changed the setting to be the following but I cannot get a spur image >>> started on mac. >>> Does anybody succeed? >>> >>> Stef >>> >> I cheated and started with latest Pharo 5 Spur and installed PharoLauncher >> from the Catalog Browser. >> (I should soon try an image with old vm) >> cheers -ben >> >> >> >

Jan. 12, 2016

Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI

by stepharo

Le 12/1/16 17:58, Denis Kudriashov a Ã©crit : > Hi > > UFFI reminds me UFO which can be translated like Unified Foreign > Objects. And it has some relation to Alien name. > But maybe it is too much funny name Quite cool :) Stef > > 2016-01-12 16:55 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com > <mailto:estebanlm@gmail.com>>: > > Hi, > > People has pointed (and they are right) that the name of the new > FFI front-end is misleading. > So yesterday I was talking with Stef and we think UnifiedFFI (or > UFFI, for short) is a better nameâ¦ and to keep packages prox. to > regular FFI I was thinking on rename FFI-NB packages to > FFI-Unifiedâ¦ but maybe is better just to rename them as UFFI or > UnifiedFFIâ¦ > what do you think? > > Esteban > > >

Jan. 12, 2016