- Pharo-dev - lists.pharo.org

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

Job offer

by stepharo

Begin forwarded message: From: Georg Heeg <georg(a)heeg.de> Subject: [Esug-list] Looking for Smalltalkers Date: 12 Jan 2016 17:57:27 GMT+1 To: ESUG Mailing list <esug-list(a)lists.esug.org> A customer of ours is looking for two Smalltalkers starting not later as July 1st, 2016, unlimited work contracts. Please contact me for details Georg Heeg Georg Heeg eK, Dortmund und KÃ¶then, HR Dortmund A 12812 Baroper Str. 337, 44227 Dortmund, Germany Tel. +49-3496-214328, Fax +49-231-97599-20 _______________________________________________ Esug-list mailing list Esug-list(a)lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

Jan. 12, 2016

Re: [Pharo-dev] Redirect bug in Zinc in the recent Pharo 5 images

by Sven Van Caekenberghe

> On 12 Jan 2016, at 15:05, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Monty, > > Thanks for reporting this issue. > > The problem is that Zn requests http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd using Host: www.oasis-open.org:80 (so with an explicit port) and apparently this server cannot directly deal with that and redirects to the same URL (but without the port) and Zn then does the same thing: ergo, an infinite loop. > > This was probably introduced a while ago when support for HTTPS Connect proxying was added. It will take me a little while to get into why it was added and if/how it can be avoided. I committed the following in #bleedingEdge: === Name: Zinc-HTTP-SvenVanCaekenberghe.444 Author: SvenVanCaekenberghe Time: 12 January 2016, 8:31:50.516464 pm UUID: 231767b6-088c-462b-8c1d-dbcdc9eb5198 Ancestors: Zinc-HTTP-SvenVanCaekenberghe.443 Revert the decision to use #authorityWithPort instead of #authority in ZnHeaders>>#request: A bug reported by Monty shows that some servers are sensitive to the default port being added Another reading of the specs seems to indicate that the default port (80 or 433) is really not needed (but not forbidden either) This might interfere with HTTPS proxying using HTTP CONNECT tunneling but that is very hard to test (see Zinc-HTTP-SvenVanCaekenberghe.437) === All tests remain green and your request now succeeds. But like I said, it is hard to test the proxying, let's hope I didn't break anything. > In any case, this is the first server that causes this ;-) > > Sven > >> On 12 Jan 2016, at 07:00, monty <monty2(a)programmer.net> wrote: >> >> When you try to retrieve this URL with recent Zinc versions, you get a max number of redirects exceeded error: >> >> http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd >> >> This is causing an XMLParser test to fail. But you can retrieve the URL fine in older images (with older versions of Zinc). I tried changing the max number of redirects to something higher, to no avail. Even when allowing hundreds of redirects, I still get the error. >> >

Jan. 12, 2016

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

by Nicolai Hess

2016-01-10 16:57 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > Hi Nicolai, > > On Sun, Jan 10, 2016 at 3:16 AM, Nicolai Hess <nicolaihess(a)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] happy lessons from recent talks

by Richard Sargent

Tudor Girba-2 wrote > Hi, > > I just wanted to share with you a bit of a different perspective on what > we do around here. > > Over the past half a year I gave several talks to some 1k technical people > at industrial events like ArchConf, NDC Oslo and several others. The tour > will continue this year at OOP, ArchConf and a couple of other places. > These are places where people talk about mainstream techniques & > technologies (like Java, JS, C#). For example, ArchConf is a premier > software architecture conference in the US. > > During these sessions, people get to experience Moose and Pharo through > live demos. I use these demos as examples of how humane assessment > (building your own analysis tools) can boost engineering decisions making > in practice. > > I consistently receive the feedback that the live programming > possibilities from Pharo/Moose are impressive. But, more recently, there > is something else worthy of being noted. If in previous years, nobody > heard about what we do, this year I started to get consistently a couple > of persons in the room that have heard something about Pharo/Moose before > the presentation. Excellent! > This is huge. While a couple might not sound like much, you should > remember that information (especially in this technical space) has the > capability of spreading exponentially. What we have done over the past > years starts to show results. We have to keep it up. > > Happy New Year! > > Cheers, > Doru > > > -- > www.tudorgirba.com > www.feenk.com > > "Problem solving should be focused on describing > the problem in a way that makes the solution obvious." -- View this message in context: http://forum.world.st/happy-lessons-from-recent-talks-tp4870566p4870941.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 12, 2016

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

by Dimitris Chloupis

Why not "Pharo FFI" ? since it will be the official FFI of Pharo. I also like like lighthouse references like "LightSpeed" , "LightForce" , "LightWave" , "Lighting", "LightHouse" etc. On Tue, Jan 12, 2016 at 5:57 PM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > 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