- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Reordering working directory mess

by Paul DeBruicker

Can't this be accomplished today with a symbolic link to a package directory somewhere on your HD? e.g. rm -rf package-cache ln -s /path/to/my/common/package/repo package-cache Works for me at least. Nicolas Passerini wrote > I agree with Javier, it would be much nicer to have only one shared > package > cache and, while I understand that there might be people not wanting that, > I don't see why it couldn't be the default behavior. I think that it would > be a reasonable default, don't you? > > On Fri, Jun 24, 2016 at 3:54 PM, Javier PimÃ¡s < > elpochodelagente@ > > > wrote: > >> I don't know for the new directories, but I always thought that it would >> be nice to have package-cache in ~/.pharo or a place shared by all >> images, >> to avoid redownloading all .MCZs from other projects each time you launch >> pharo from a different directory. >> >> Cheers! >> Pocho >> >> On Thu, Jun 23, 2016 at 12:22 PM, Esteban Lorenzano < > estebanlm@ > > >> wrote: >> >>> Hi, >>> >>> Since some time Iâve seen growing the amount of files/directories >>> generated when running Pharo. Up to Pharo 2.0, we had just this: >>> >>> Pharo.image >>> Pharo.changes >>> PharoDebug.log >>> pharo-cache >>> >>> now we have: >>> >>> Pharo.image >>> Pharo.changes >>> PharoDebug.log >>> pharo-cache >>> epicea-sessions >>> play-cache >>> play-stash >>> >>> it does not looks like much, but I think this does not looks >>> professional >>> (we take too much from user space). So I proposed (and implemented) a >>> âconcentratorâ directory: >>> >>> Pharo.image >>> Pharo.changes >>> ./pharo >>> â¦ and everything for âpharo working internallyâ here >>> >>> then users have again control about what they have along with the image >>> (this allows to some nice strategies too, when we want a version that >>> does >>> not pollutes the file dir). >>> >>> of course, this idea follows other developing spaces, where things are >>> stored in same fashion wayâ¦ for example in eclipse for java they store >>> all >>> eclipse data under .workspace directory. >>> >>> so, please note that this is NOT user spaceâ¦ regular pharo users will >>> store his files along with the image, for instance filetree >>> repositoriesâ¦ >>> something like: >>> >>> Pharo.image >>> Pharo.changes >>> .pharo/ >>> voyage/ >>> punqlite/ >>> etc. >>> >>> wellâ¦ I will commit a SLICE with the changes soon (is not a hard change >>> at all). >>> >>> But then: >>> >>> is ./pharo a good name? >>> will this work? >>> >>> Esteban >>> >> >> >> >> -- >> Javier PimÃ¡s >> Ciudad de Buenos Aires >> -- View this message in context: http://forum.world.st/Reordering-working-directory-mess-tp4902671p4903118.h… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 24, 2016

Re: [Pharo-dev] Reordering working directory mess

by Esteban Lorenzano

> On 24 Jun 2016, at 18:14, Nicolas Passerini <npasserini(a)gmail.com> wrote: > > I agree with Javier, it would be much nicer to have only one shared package cache and, while I understand that there might be people not wanting that, I don't see why it couldn't be the default behavior. I think that it would be a reasonable default, don't you? I agreeâ¦ but where to store them? same place as âpreferencesâ? real problem with this is that you reduce a little bit âportabilityâ of Pharo, because you store files outside the root directoryâ¦ but we already do that, so I would agree :P Esteban > > On Fri, Jun 24, 2016 at 3:54 PM, Javier PimÃ¡s <elpochodelagente(a)gmail.com <mailto:elpochodelagente@gmail.com>> wrote: > I don't know for the new directories, but I always thought that it would be nice to have package-cache in ~/.pharo or a place shared by all images, to avoid redownloading all .MCZs from other projects each time you launch pharo from a different directory. > > Cheers! > Pocho > > On Thu, Jun 23, 2016 at 12:22 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > Hi, > > Since some time Iâve seen growing the amount of files/directories generated when running Pharo. Up to Pharo 2.0, we had just this: > > Pharo.image > Pharo.changes > PharoDebug.log > pharo-cache > > now we have: > > Pharo.image > Pharo.changes > PharoDebug.log > pharo-cache > epicea-sessions > play-cache > play-stash > > it does not looks like much, but I think this does not looks professional (we take too much from user space). So I proposed (and implemented) a âconcentratorâ directory: > > Pharo.image > Pharo.changes > ./pharo > â¦ and everything for âpharo working internallyâ here > > then users have again control about what they have along with the image (this allows to some nice strategies too, when we want a version that does not pollutes the file dir). > > of course, this idea follows other developing spaces, where things are stored in same fashion wayâ¦ for example in eclipse for java they store all eclipse data under .workspace directory. > > so, please note that this is NOT user spaceâ¦ regular pharo users will store his files along with the image, for instance filetree repositoriesâ¦ something like: > > Pharo.image > Pharo.changes > .pharo/ > voyage/ > punqlite/ > etc. > > wellâ¦ I will commit a SLICE with the changes soon (is not a hard change at all). > > But then: > > is ./pharo a good name? > will this work? > > Esteban > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires >

June 24, 2016

Re: [Pharo-dev] Having comments for pragma?

by Ben Coman

On Fri, Jun 24, 2016 at 10:55 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hi. > > Pragmas are selectors hence they're browsable. You can implement a method > somewhere with the pragma selector name that includes the documentation. In > VW they were careful about that and most, if not all, of their pragmas are > carefully commented this way. > > Should this be concentrated in a class like PragmaDocumentation, or spread out (I don't know how). cheers -ben > For example, if you have the pragma <foo> and you implement the method > MyClass class >> #foo with some comments in it and you can double click on > the pragma <foo> to select its content (foo) and press Cmd+M (or right > click implementors) to get to the method having the documentation. > > > On Fri, Jun 24, 2016 at 3:54 PM, Alexandre Bergel <alexandre.bergel(a)me.com > > wrote: > >> Hi! >> >> A pragma may be very obscure. For example, I do: >> Pragma allInstances anyOne >> => <debuggerCompleteToSender> >> >> If I want to know more about this <debuggerCompleteToSender> is actually >> quite challenging. >> I see many methods having that pragma, but not idea what it is for. >> I see that Halt>>signalerContext and Process>>complete: that use that >> pragma somehow. But still, I have no idea when I should use that pragma in >> my method. >> >> What about having a way to comment pragma? Maybe something like >> -=-=-=-=-=-= >> Object subclass: #Pragma >> instanceVariableNames: 'method keyword arguments *comment*' >> -=-=-=-=-=-= >> >> And a simple way to annotate pragmas? >> Just an idea. >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >

June 24, 2016

Re: [Pharo-dev] Having comments for pragma?

by Eliot Miranda

> On Jun 24, 2016, at 7:55 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Hi. > > Pragmas are selectors hence they're browsable. You can implement a method somewhere with the pragma selector name that includes the documentation. In VW they were careful about that and most, if not all, of their pragmas are carefully commented this way. > > For example, if you have the pragma <foo> and you implement the method MyClass class >> #foo with some comments in it and you can double click on the pragma <foo> to select its content (foo) and press Cmd+M (or right click implementors) to get to the method having the documentation. +1. I can't stress enough how useful it is to make pragmas real selectors with implementations and to try and apply them using perform:withArguments:. That's when their real power comes in. For example, if you have some method that wants to be added to some tool, make its pragma a message with all the information you need to add it as arguments (things like its position or priority relative to other additions, its name in the list of components, an icon to use, a string for fly-by help) and then implement a builder class whose methods match these pragmas so that when the builder performs the pragma it adds the method to the tool, in a given position, with a given icon and fly-by help etc. In most other systems method annotations are simply that, just passive labels. But in Smalltalk these are executable. You can browse for senders and implementors, you can execute them using a visitor pattern. Much more powerful. > >> On Fri, Jun 24, 2016 at 3:54 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> Hi! >> >> A pragma may be very obscure. For example, I do: >> Pragma allInstances anyOne >> => <debuggerCompleteToSender> >> >> If I want to know more about this <debuggerCompleteToSender> is actually quite challenging. >> I see many methods having that pragma, but not idea what it is for. >> I see that Halt>>signalerContext and Process>>complete: that use that pragma somehow. But still, I have no idea when I should use that pragma in my method. >> >> What about having a way to comment pragma? Maybe something like >> -=-=-=-=-=-= >> Object subclass: #Pragma >> instanceVariableNames: 'method keyword arguments comment' >> -=-=-=-=-=-= >> >> And a simple way to annotate pragmas? >> Just an idea. >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >

June 24, 2016

Re: [Pharo-dev] Reordering working directory mess

by Nicolas Passerini

I agree with Javier, it would be much nicer to have only one shared package cache and, while I understand that there might be people not wanting that, I don't see why it couldn't be the default behavior. I think that it would be a reasonable default, don't you? On Fri, Jun 24, 2016 at 3:54 PM, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: > I don't know for the new directories, but I always thought that it would > be nice to have package-cache in ~/.pharo or a place shared by all images, > to avoid redownloading all .MCZs from other projects each time you launch > pharo from a different directory. > > Cheers! > Pocho > > On Thu, Jun 23, 2016 at 12:22 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> Hi, >> >> Since some time Iâve seen growing the amount of files/directories >> generated when running Pharo. Up to Pharo 2.0, we had just this: >> >> Pharo.image >> Pharo.changes >> PharoDebug.log >> pharo-cache >> >> now we have: >> >> Pharo.image >> Pharo.changes >> PharoDebug.log >> pharo-cache >> epicea-sessions >> play-cache >> play-stash >> >> it does not looks like much, but I think this does not looks professional >> (we take too much from user space). So I proposed (and implemented) a >> âconcentratorâ directory: >> >> Pharo.image >> Pharo.changes >> ./pharo >> â¦ and everything for âpharo working internallyâ here >> >> then users have again control about what they have along with the image >> (this allows to some nice strategies too, when we want a version that does >> not pollutes the file dir). >> >> of course, this idea follows other developing spaces, where things are >> stored in same fashion wayâ¦ for example in eclipse for java they store all >> eclipse data under .workspace directory. >> >> so, please note that this is NOT user spaceâ¦ regular pharo users will >> store his files along with the image, for instance filetree repositoriesâ¦ >> something like: >> >> Pharo.image >> Pharo.changes >> .pharo/ >> voyage/ >> punqlite/ >> etc. >> >> wellâ¦ I will commit a SLICE with the changes soon (is not a hard change >> at all). >> >> But then: >> >> is ./pharo a good name? >> will this work? >> >> Esteban >> > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires >

June 24, 2016

debuggerCompleteToSender (was Re: Having comments for pragma?)

by Ben Coman

On Fri, Jun 24, 2016 at 9:54 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > A pragma may be very obscure. For example, I do: > Pragma allInstances anyOne > => <debuggerCompleteToSender> > > If I want to know more about this <debuggerCompleteToSender> is actually > quite challenging. > I see many methods having that pragma, but not idea what it is for. > I see that Halt>>signalerContext and Process>>complete: that use that > pragma somehow. But still, I have no idea when I should use that pragma in > my method. > > Sorry I don't know enough of Pragma architecture to form an opinion on your question, but I can give you some background on debuggerCompleteToSender. There are two cases where the debugger interacts with a halt statement. The first is when a halt is first encountered in running code. This could be "Halt now" or "self halt" which respectively invoke... Halt>>now self signal. Object>>halt Halt now. Now you don't want the debugger to open in those methods, but the method that sent the message. The problem with the implementation prior to <debuggerCompleteToSender> was that while it was okay for signalerContext to be search the context chain for a Halt object so the debugger could open in the sender of #now, that meant the debugger would open inside "self halt" since it sends #now. So there was an #or: to look for #halt being sent, and an #or: for #haltOnce beign sent, and the dozen other senders of Halt>>now were ignored, or otherwise you'd need a dozen #or: conditions. The second case is when you are stepping through code you come across another "self haltOnce" and previously when you <Step Over> the debugger would end up several methods "in" and it would take eight or so <Steps> to get back out to the method containing the "self halt". (and this really annoyed me enough to fix it). So DebuggSession>>stepOver: calls Process>>completeStep: which calls Process>>complete: Again (vaguely I remember) it originally only searched up the context chain for senders of #halt and the dozen others halt methods were ignored and so they failed to set the debugger to the correct location. >From from #complete: the call "self completeTo: aContext sender" moves up the context chain, and completeTo: recurses back to complete. This recursion only happens while the error class is Halt and while the context methods have the pragma, otherwise it falls through to return suspendedContext as it unwinds. So having written all that to remind myself, the short answer of the net effect is that a first method with <debuggerCompleteToSender> can call another method with <debuggerCompleteToSender> which can call another <debuggerCompleteToSender> methods etc to any depth, until eventually Halt>>now is called to signal the exception, then all calls get unwound up to the first method with <debuggerCompleteToSender>, and the debugger lands in its sender. I was not completely happy with the pragma's name, but I was really at a loss what to name it, and so... since I was fixing the debugger, and was all happening in the "completion" machinery, and it unwound to the sender... *shrugs* Now, where to add all that as a comment? HTH, cheers -ben

June 24, 2016

Re: [Pharo-dev] OS-Windows and UnifiedFFI

by Esteban Lorenzano

> On 24 Jun 2016, at 16:43, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-06-24 16:03 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > if you send me the code, I can take a look. > > Sorry if this sounds rude, but > did you actually read my mail, I mean the first one. wellâ¦ after search, it was from 25 aprâ¦ and my client didnât show it to me (because I removed it, to clean)â¦ and it folded the quoted so yes, I read itâ¦ like a month ago :) > > If you don't have the time to look at this, it is ok. I will just try to find it out myself, or maybe torsten has an idea. > No problem. well, but Iâm particularly interested in UFFI, since is my new toy :) and seriously, I want to make him really solid, so I jump in whenever I see a problem, even if Iâm doing something different (merging pharo-vm with os-vm, now). Anyway, I see the error: WinWndClassEx is generated with bad mappingâ¦ this is fixed in new versions of UFFI so you need to regenerate the fields: WinWndClassEx rebuildFieldAccessors. (Torsten needs to but thenâ¦ I spotted a bug, because FFIConstantHandle>>value is not defined so you will still have an error :) anyway, I updated both, OSWindow and UFFI so if I you load bleedingEdge of both, you will see something like this: > > I already posted the code multiple times. There is no code I could send. It is all in the image (+ the OSWindow) project. > > I'll try it again. > > OS: Windows > - take a fresh > - load (from catalog browser) OSWindow > > - execute this > > | hInst wndClass | > hInst := WinProcess getVMModuleHandle. > wndClass := WinWndClassEx new. > wndClass hInstance: hInst. > > Error : > Unable to resolve external type: HMODULE > > OK, getVMModuleHandle expects a HMODULE type > We need to define a missing type, HMODULE, but that works (just like all the other H-WinHandle-Types). > > Now execute it again: > New error: > "MessageNotUnderstood: SmallInteger>>isExternalAddress" > > The question is: > > Any Idea what is missing here, I need a way to store the HMODULE handle > in the structure of the WinWNdClassEx >

June 24, 2016

Re: [Pharo-dev] Having comments for pragma?

by ClÃ©ment Bera

Hi. Pragmas are selectors hence they're browsable. You can implement a method somewhere with the pragma selector name that includes the documentation. In VW they were careful about that and most, if not all, of their pragmas are carefully commented this way. For example, if you have the pragma <foo> and you implement the method MyClass class >> #foo with some comments in it and you can double click on the pragma <foo> to select its content (foo) and press Cmd+M (or right click implementors) to get to the method having the documentation. On Fri, Jun 24, 2016 at 3:54 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > A pragma may be very obscure. For example, I do: > Pragma allInstances anyOne > => <debuggerCompleteToSender> > > If I want to know more about this <debuggerCompleteToSender> is actually > quite challenging. > I see many methods having that pragma, but not idea what it is for. > I see that Halt>>signalerContext and Process>>complete: that use that > pragma somehow. But still, I have no idea when I should use that pragma in > my method. > > What about having a way to comment pragma? Maybe something like > -=-=-=-=-=-= > Object subclass: #Pragma > instanceVariableNames: 'method keyword arguments *comment*' > -=-=-=-=-=-= > > And a simple way to annotate pragmas? > Just an idea. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

June 24, 2016

Re: [Pharo-dev] OS-Windows and UnifiedFFI

by Nicolai Hess

2016-06-24 16:03 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > if you send me the code, I can take a look. > > Sorry if this sounds rude, but did you actually read my mail, I mean the first one. If you don't have the time to look at this, it is ok. I will just try to find it out myself, or maybe torsten has an idea. No problem. I already posted the code multiple times. There is no code I could send. It is all in the image (+ the OSWindow) project. I'll try it again. OS: Windows - take a fresh - load (from catalog browser) OSWindow - execute this | hInst wndClass | hInst := WinProcess getVMModuleHandle. wndClass := WinWndClassEx new. wndClass hInstance: hInst. Error : Unable to resolve external type: HMODULE OK, getVMModuleHandle expects a HMODULE type We need to define a missing type, HMODULE, but that works (just like all the other H-WinHandle-Types). Now execute it again: New error: "MessageNotUnderstood: SmallInteger>>isExternalAddress" The question is: Any Idea what is missing here, I need a way to store the HMODULE handle in the structure of the WinWNdClassEx

June 24, 2016

Re: [Pharo-dev] Impossible to delete a class

by Max Leske

> On 24 Jun 2016, at 16:18, Valentin Ryckewaert <valentin.ryckewaert(a)gmail.com> wrote: > > Hello everyone, > > I just downloaded the last Pharo version and I found a bug when I tried to delete a class. > The last version deprecated a method "name" and it looks like SmalltalkImage>>errorReportOn: doesn't like this. When you try to delete a class there is an infinite loop everytime. Nice find! Please open a bug report. It probably wonât be the last one related to the removal of #name. Cheers, Max > > Valentin

June 24, 2016