- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Abbreviations

by Max Leske

On 04.07.2013, at 13:09, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Jul 4, 2013, at 12:52 , Torsten Bergmann wrote: > >> Usually I thought only the C/C++ people fell in love with abbreviations - but >> now its our own community: >> >> in Pharo 3.0 one can write: >> >> Smalltalk os env >> >> or would it be better to use: >> >> Smalltalk operatingSystem environment >> >> in the future? >> >> So is the current >> >> Smalltalk vm >> >> better than >> >> Smalltalk virtualMachine >> >> I know: even a newcomer should know what "OS" means. At least Smalltalkers/Java people should >> know they need a "VM". But nonetheless I think a common goal would be to keep >> Pharo code and method selectors readable and avoid abbreviations when possible. >> >> Also there are Pharo methods like #getEnv: instead of #getEnvironmentVariable: >> (interesting that they wrap the native C/C++ API "GetEnvironmentVariableA" >> which does not use abbreviations) >> >> Should we care (with an issue) and use the more readable forms in >> the future and deprecated the abbreviation forms? >> >> Or will we keep abbreviations for the lazy and easier typing? >> >> If you comment please think about the goal to get readable code, the goal to >> get more newcomers into programming and your own first steps with Smalltalk >> and IT ... > > My 2c: > Acronyms work fine, also in method names. (os, vm) > As a basic rule require to spell out ante meridiem, light amplification by stimulated emission of radiation, radio detection and ranging, compact disk, and their likes, seems a bit â¦ zealous. Agreed. There are conventional terms that can (and maybe should) be abbreviated. But in general I'm against abbreviations. > > Simple abbreviations, like env, rather than using the full word, I have much less empathy for. > > Cheers, > Henry

July 4, 2013

Re: [Pharo-dev] Abbreviations

by Norbert Hartl

Am 04.07.2013 um 13:09 schrieb Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On Jul 4, 2013, at 12:52 , Torsten Bergmann wrote: > >> Usually I thought only the C/C++ people fell in love with abbreviations - but >> now its our own community: >> >> in Pharo 3.0 one can write: >> >> Smalltalk os env >> >> or would it be better to use: >> >> Smalltalk operatingSystem environment >> >> in the future? >> >> So is the current >> >> Smalltalk vm >> >> better than >> >> Smalltalk virtualMachine >> >> I know: even a newcomer should know what "OS" means. At least Smalltalkers/Java people should >> know they need a "VM". But nonetheless I think a common goal would be to keep >> Pharo code and method selectors readable and avoid abbreviations when possible. >> >> Also there are Pharo methods like #getEnv: instead of #getEnvironmentVariable: >> (interesting that they wrap the native C/C++ API "GetEnvironmentVariableA" >> which does not use abbreviations) >> >> Should we care (with an issue) and use the more readable forms in >> the future and deprecated the abbreviation forms? >> >> Or will we keep abbreviations for the lazy and easier typing? >> >> If you comment please think about the goal to get readable code, the goal to >> get more newcomers into programming and your own first steps with Smalltalk >> and IT ... > > My 2c: > Acronyms work fine, also in method names. (os, vm) > As a basic rule require to spell out ante meridiem, light amplification by stimulated emission of radiation, radio detection and ranging, compact disk, and their likes, seems a bit â¦ zealous. > > Simple abbreviations, like env, rather than using the full word, I have much less empathy for. > I like to avoid abbreviations as much as possible. But you are right when it comes to use very common ones I don't have a strong feeling about. To me I think vm and os are widely used so there is nothing to decipher in order to be able to understand it. The selector env I find not commonly used ( I know it mostly from console usage ). And there is Behavior>>#environment which I feel is inconsistent. Norbert

July 4, 2013

Re: [Pharo-dev] Abbreviations

by Norbert Hartl

+ One Norbert Am 04.07.2013 um 12:52 schrieb "Torsten Bergmann" <astares(a)gmx.de>: > Usually I thought only the C/C++ people fell in love with abbreviations - but > now its our own community: > > in Pharo 3.0 one can write: > > Smalltalk os env > > or would it be better to use: > > Smalltalk operatingSystem environment > > in the future? > > So is the current > > Smalltalk vm > > better than > > Smalltalk virtualMachine > > I know: even a newcomer should know what "OS" means. At least Smalltalkers/Java people should > know they need a "VM". But nonetheless I think a common goal would be to keep > Pharo code and method selectors readable and avoid abbreviations when possible. > > Also there are Pharo methods like #getEnv: instead of #getEnvironmentVariable: > (interesting that they wrap the native C/C++ API "GetEnvironmentVariableA" > which does not use abbreviations) > > Should we care (with an issue) and use the more readable forms in > the future and deprecated the abbreviation forms? > > Or will we keep abbreviations for the lazy and easier typing? > > If you comment please think about the goal to get readable code, the goal to > get more newcomers into programming and your own first steps with Smalltalk > and IT ... > > > > >

July 4, 2013

Re: [Pharo-dev] Abbreviations

by Henrik Johansen

On Jul 4, 2013, at 12:52 , Torsten Bergmann wrote: > Usually I thought only the C/C++ people fell in love with abbreviations - but > now its our own community: > > in Pharo 3.0 one can write: > > Smalltalk os env > > or would it be better to use: > > Smalltalk operatingSystem environment > > in the future? > > So is the current > > Smalltalk vm > > better than > > Smalltalk virtualMachine > > I know: even a newcomer should know what "OS" means. At least Smalltalkers/Java people should > know they need a "VM". But nonetheless I think a common goal would be to keep > Pharo code and method selectors readable and avoid abbreviations when possible. > > Also there are Pharo methods like #getEnv: instead of #getEnvironmentVariable: > (interesting that they wrap the native C/C++ API "GetEnvironmentVariableA" > which does not use abbreviations) > > Should we care (with an issue) and use the more readable forms in > the future and deprecated the abbreviation forms? > > Or will we keep abbreviations for the lazy and easier typing? > > If you comment please think about the goal to get readable code, the goal to > get more newcomers into programming and your own first steps with Smalltalk > and IT ... My 2c: Acronyms work fine, also in method names. (os, vm) As a basic rule require to spell out ante meridiem, light amplification by stimulated emission of radiation, radio detection and ranging, compact disk, and their likes, seems a bit â¦ zealous. Simple abbreviations, like env, rather than using the full word, I have much less empathy for. Cheers, Henry

July 4, 2013

Re: [Pharo-dev] Abbreviations

by Peter Hugosson-Miller

+1000 On Thu, Jul 4, 2013 at 12:57 PM, Max Leske <maxleske(a)gmail.com> wrote: > I agree wholeheartedly! I still believe in (mostly) self documenting code > and that cannot be achieved by using abbreviations. > > Max > > On 04.07.2013, at 12:52, Torsten Bergmann <astares(a)gmx.de> wrote: > > > Usually I thought only the C/C++ people fell in love with abbreviations > - but > > now its our own community: > > > > in Pharo 3.0 one can write: > > > > Smalltalk os env > > > > or would it be better to use: > > > > Smalltalk operatingSystem environment > > > > in the future? > > > > So is the current > > > > Smalltalk vm > > > > better than > > > > Smalltalk virtualMachine > > > > I know: even a newcomer should know what "OS" means. At least > Smalltalkers/Java people should > > know they need a "VM". But nonetheless I think a common goal would be to > keep > > Pharo code and method selectors readable and avoid abbreviations when > possible. > > > > Also there are Pharo methods like #getEnv: instead of > #getEnvironmentVariable: > > (interesting that they wrap the native C/C++ API > "GetEnvironmentVariableA" > > which does not use abbreviations) > > > > Should we care (with an issue) and use the more readable forms in > > the future and deprecated the abbreviation forms? > > > > Or will we keep abbreviations for the lazy and easier typing? > > > > If you comment please think about the goal to get readable code, the > goal to > > get more newcomers into programming and your own first steps with > Smalltalk > > and IT ... > > > > > > > > > > > > > -- Cheers,

July 4, 2013

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

by Goubier Thierry

Le 04/07/2013 11:58, Igor Stasenko a Ã©crit : > On 3 July 2013 23:04, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: >> Hi Stephane, >> >> I worked around it... as long as I don't make FileReference>>exists as a NB call, then the Changes file will open correctly and NB calls will work after that (Changes opening doesn't use isReadable or isWriteable, which is interesting in itself ;))... But it makes my solution fragile. >> >> However, if you make the Changes file not readable (still owned by you, still writeable), many interesting things happen, starting with a nbGetEnv failure and a total unability to quit Pharo apart from a killall pharo. >> >> I tried to: >> - Get NB to accept positional arguments instead of named ones (by catching names like _1, _2). Easy, since apparently the NB generated code just takes an offset on the pointer stack finally (i.e. names are only used to get the index in the arguments array). Seemed to work. > > can you share this code? i think it doesn't hurts being able to refer > to method argument by number , not by name, if author wants to. 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 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. >> - Change all NB calls with numbers above to be able to have NB working before / without the Changes file. >> Ended with a segfault on startup (globalSymbolLoading for GetEnv again), and I gave up. >> >> Igor, would there be a way to write the call with the effective arguments instead of #symbols, so that by looking at the bytecode you would get the position in the arguments stack? Or would it be possible to store by hand the source of the methods (triggered by the <pragma>) inside a source cache inside NB for the time being? Or is there an event for NB correct start (with Changes and all ready) so that we can write NB code with a fallback if NB isn't able to work? >> > i wanna change it, so that when you compile method with NB primitive, > it remembers the arg names. Yes, I suspect it would be the best solution. Trap on <primitive: ? If you track the MethodAdded / MethodRemoved events, you can note all uses of <primitive:> and cache the info there ? >> NB made it so easy to do simple and usefull calls to external libs that I really want it to work! >> >> Thierry >> >> ________________________________________ >> De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] >> Date d'envoi : mercredi 3 juillet 2013 21:51 >> Ã : Pharo Development List >> Objet : Re: [Pharo-dev] NativeBoost with no access to sources >> >>>> >>> I don't know.. look: >>> >>> realloc: flags mem: lpMem size: dwBytes >>> >>> <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode> >>> >>> >>> ^ self nbCall: >>> #( LPVOID HeapReAlloc (self, DWORD flags, LPVOID lpMem, SIZE_T dwBytes) ) >>> >>> here, see: flags, lpMem, dwBytes names is in function signature same >>> as in your method. >>> That's how NB knows which argument from method corresponds to argument >>> passed to function. >>> >>> now if you don't use argument names , how the above should look like? >>> >>> realloc: flags mem: lpMem size: dwBytes >>> >>> <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode> >>> >>> ^ self nbCall: >>> #( LPVOID HeapReAlloc (self, DWORD @1, LPVOID @2, SIZE_T @3) ) >>> ? >> >> >> Igor I understand your concerns but also the problem thierry is facing and it looks to me like a valid scenario. >> >> Stef >> > > > -- 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 4, 2013

Re: [Pharo-dev] Abbreviations

by Max Leske

I agree wholeheartedly! I still believe in (mostly) self documenting code and that cannot be achieved by using abbreviations. Max On 04.07.2013, at 12:52, Torsten Bergmann <astares(a)gmx.de> wrote: > Usually I thought only the C/C++ people fell in love with abbreviations - but > now its our own community: > > in Pharo 3.0 one can write: > > Smalltalk os env > > or would it be better to use: > > Smalltalk operatingSystem environment > > in the future? > > So is the current > > Smalltalk vm > > better than > > Smalltalk virtualMachine > > I know: even a newcomer should know what "OS" means. At least Smalltalkers/Java people should > know they need a "VM". But nonetheless I think a common goal would be to keep > Pharo code and method selectors readable and avoid abbreviations when possible. > > Also there are Pharo methods like #getEnv: instead of #getEnvironmentVariable: > (interesting that they wrap the native C/C++ API "GetEnvironmentVariableA" > which does not use abbreviations) > > Should we care (with an issue) and use the more readable forms in > the future and deprecated the abbreviation forms? > > Or will we keep abbreviations for the lazy and easier typing? > > If you comment please think about the goal to get readable code, the goal to > get more newcomers into programming and your own first steps with Smalltalk > and IT ... > > > > >

July 4, 2013

Abbreviations

by Torsten Bergmann

Usually I thought only the C/C++ people fell in love with abbreviations - but now its our own community: in Pharo 3.0 one can write: Smalltalk os env or would it be better to use: Smalltalk operatingSystem environment in the future? So is the current Smalltalk vm better than Smalltalk virtualMachine I know: even a newcomer should know what "OS" means. At least Smalltalkers/Java people should know they need a "VM". But nonetheless I think a common goal would be to keep Pharo code and method selectors readable and avoid abbreviations when possible. Also there are Pharo methods like #getEnv: instead of #getEnvironmentVariable: (interesting that they wrap the native C/C++ API "GetEnvironmentVariableA" which does not use abbreviations) Should we care (with an issue) and use the more readable forms in the future and deprecated the abbreviation forms? Or will we keep abbreviations for the lazy and easier typing? If you comment please think about the goal to get readable code, the goal to get more newcomers into programming and your own first steps with Smalltalk and IT ...

July 4, 2013

Re: [Pharo-dev] All websites are back online!

by Martin Dias

+1 On Thu, Jul 4, 2013 at 12:23 PM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > > > > On Thu, Jul 4, 2013 at 12:11 PM, Benjamin > <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> >> Cool :) >> >> Congratulation for your reactivity :) > > > +1 > >> >> >> Ben >> >> On Jul 4, 2013, at 12:08 PM, Nicolas Petton <petton.nicolas(a)gmail.com> >> wrote: >> >> We got the power back :) >> I recovered the databases for all 3 websites, and restarted them. >> >> Cheers, >> Nico >> >> >> >> >> On Jul 4, 2013, at 11:47 AM, Nicolas Petton <petton.nicolas(a)gmail.com> >> wrote: >> >> Hi! >> >> All our services (including backup servers) are currently down due to >> power issues with ERDF at our datacenter (you can follow it on twitter) >> https://twitter.com/online_fr/ >> They were running on a generator power for some time, but it seem to have >> finally failed too. >> >> All their support lines are busy, and we can't reach them by email either. >> >> I'm doing my best to resolve the issue as soon as possible, they promised >> us that the power would be back in 20'. >> >> I'm really sorry for the inconvenience. >> >> Cheers, >> Nico >> >> >> -- >> Nicolas Petton >> http://www.nicolas-petton.fr >> >> >> >

July 4, 2013

Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL

by StÃ©phane Ducasse

ok we should write that in the NB chapter. On Jul 3, 2013, at 10:36 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > I'm just guessing, but if a function receives a pointer, it does not store the pointer anywhere but works with the contents, and finally returns while VM is blocked, voilÃ¡ :). > > > On Wed, Jul 3, 2013 at 10:13 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> >> if you pass a pointer to something in object memory into function, >> make sure GC cannot move the object while function uses/accessing its contents. > > How? > > >

July 4, 2013