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

Re: [Pharo-dev] Reordering working directory mess

by Sven Van Caekenberghe

This is optional (some people want it, others not) System settings > Monticello > Local cache directory MCCacheDirectory class>>#cacheDirectory: > On 24 Jun 2016, at 15:54, 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

Re: [Pharo-dev] Reordering working directory mess

by Serge Stinckwich

This is already possible to have a shared directory for all the *.mcz of your images. On 6/24/16, 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 > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

June 24, 2016

Re: [Pharo-dev] catalog will be down 1hr

by Serge Stinckwich

When informations in the catalog are updated ? I made some modifications yesterday and apparently they didn't appear, but maybe I just have to wait more :-) On 6/21/16, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > I will apply some updates to catalog (backend, they will not be visible) > > cheers, > Esteban > > > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

June 24, 2016

Having comments for pragma?

by Alexandre Bergel

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 Javier PimÃ¡s

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

[pharo-project/pharo-core] b637cf: 60112

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: b637cf9547873482910a1cf6159b60d220b6e0c9 https://github.com/pharo-project/pharo-core/commit/b637cf9547873482910a1cf6… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-24 (Fri, 24 Jun 2016) Changed paths: A ConfigurationOfTxText.package/ConfigurationOfTxText.class/instance/versions/version2125_.st M Kernel.package/Halt.class/class/halting/once.st M Ring-Core-Kernel.package/RGElementDefinition.class/instance/accessing/package.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60111.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60112.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60111.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60112.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M TxText-Athens.package/TxAdapterBindings.class/instance/initialize/initializeBindings.st R TxText-Model.package/TxModel.class/instance/copying/postCopy.st Log Message: ----------- 60112 18597 fix haltOnce to open debugger in the right place https://pharo.fogbugz.com/f/cases/18597 18539 Can not browse methods for a change set that modified class comments https://pharo.fogbugz.com/f/cases/18539 18073 TxModel >>#postCopy sends #halt https://pharo.fogbugz.com/f/cases/18073 http://files.pharo.org/image/60/60112.zip

June 24, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60112 Home: https://github.com/pharo-project/pharo-core

June 24, 2016

Re: [Pharo-dev] Reordering working directory mess

by Max Leske

> On 24 Jun 2016, at 14:36, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > so, pharo-local will be. > but regular convention is to store this kind of data into a hidden directory (hence it would be .pharo-local, maybe)â¦ but I understand the opposition I will let it visible and we can re-check later. My hero! :) > > now, tool makers, please take into account the new > > FileLocator localDirectory > > Esteban > > ps: and yes, Iâm adding a setting so you can modify default local directory :) > >> On 24 Jun 2016, at 11:35, Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: >> >> Hi, >> >>> On Jun 23, 2016, at 10:18 PM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >>> >>> What is the difference between play-cache play-stash >> >> - play-cache is populated automatically when you work in the playground. >> - play-stash stores only the pages that you gave concrete names to. You can double click on the tab with the name of a page and you can give it another name than Untitled. In this case, the file is copied in the play-stash folder and you can search for it by name. For example, using this mechanism you can name a script that you use for loading a piece of code and find it from spotter. >> >> Cheers, >> Doru >> >> >>> Stef >>> >>> >>> Le 23/6/16 Ã 17:22, Esteban Lorenzano a Ã©crit : >>>> 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 >>>> >>> >>> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com/> >> www.feenk.com <http://www.feenk.com/> >> >> "Every thing should have the right to be different." >

June 24, 2016

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

by Nicolai Hess

2016-06-24 14:52 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 24 Jun 2016, at 14:40, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-06-24 14:32 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> â¦ and I enhanced the example to not induce to confusion anymore :) >> >> Esteban >> > > Sorry, I must be stupid, it still does not work ( and it actually looks > the same as with the existing WinHandle type). > > > well, that I donât knowâ¦ for me it works, I tested it in Win10 and it was > fine. > What was fine? > What exactly are you trying to do? > As I wrote, I try to get the vmmodule handle (WinProcess getVMModuleHandle) and assign it to the hInstance field of a WinWndClassEx, getting the vm module handle works, (both, if I use the existing WinHandle type or (like you) a direct FFIConstantHandle). But assigning this value to the hInstance field always gives a DNU MessageNotUnderstood: SmallInteger>>isExternalAddress I do understant that a WinHandle is not an external (memory) resource and has no external address. I just don't undestand how to pass this type of arguments. > > Esteban > > > > >> >> On 24 Jun 2016, at 14:27, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >> >> >> 2016-06-24 14:05 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >>> >>> On 24 Jun 2016, at 09:53, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>> >>> >>> >>> Iâm sorryâ¦ I do not understand. This is solved in UFFI since some >>>> months, and Torstenâs OSWindow uses it. >>>> >>> >>> Sorry then it is my fault. I know that Torsten already ported OSWindow >>> to UFFI, and that most things are already working. >>> >>> UFFI provides FFIConstantHandle type to deal with windows HANDLE types, >>>> as comment says: >>>> >>>> I represent a constant HANDLE, as described in *Windows MSDN> >>>> https://msdn.microsoft.com/en-us/library/windows/desktop/ms724457(v=vs.85).… >>>> >>>> A ==HANDLE== is a special kind of external object who is accessed >>>> through numbers, therefore and ==ExternalAddress== is not appropriate to >>>> describe it (since they are constants and external addresses represents >>>> disposable spaces from memory). >>>> >>>> Is not clear this is necessary outside Windows, but according to >>>> documentation they are somekind analogous to unix's File Descriptors (but >>>> with some remarkable diferences, as documented *here> >>>> http://lackingrhoticity.blogspot.fr/2015/05/passing-fds-handles-between-pro… >>>> . >>>> >>>> Example: >>>> [[[ >>>> HWND := #FFIConstantHandle. >>>> self ffiCall: #(HWND GetActiveWindow()) >>>> ]]] >>>> >>> >>>> is there anything Iâm missing? >>>> >>> >>> I don't know what else should I do, I already posted the example. >>> The code I provided just don't work (DNU on isExternalAddress, see other >>> mail), and I have no idea how to make it work. >>> Yes, maybe I don't know enough about ffi for this type of the function >>> argument passing. >>> >>> >>> the example is a simplification, you cannot put both definition and call >>> in same methodâ¦ find attached a working example of what you want. >>> >> >> >> Thank you! >> >> >>> >>> >>> >>> >>> >>> (actually I tried to port some NBOpenGL code to UFFI, for this I need to >>> register a Window Class with WinWndClassEx (to create a gl context). >>> So if this *is* already working, I need to look what I have done wrong). >>> >>> thanks for your response. >>> nicolai >>> >>> >>> >>>> >>>> Esteban >>>> >>> >> > >

June 24, 2016

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

by Esteban Lorenzano

ah, and which VM are you using? > On 24 Jun 2016, at 14:40, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-06-24 14:32 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > â¦ and I enhanced the example to not induce to confusion anymore :) > > Esteban > > Sorry, I must be stupid, it still does not work ( and it actually looks the same as with the existing WinHandle type). > > > >> On 24 Jun 2016, at 14:27, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: >> >> >> >> 2016-06-24 14:05 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >> >>> On 24 Jun 2016, at 09:53, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: >>> >>> >>> >>> Iâm sorryâ¦ I do not understand. This is solved in UFFI since some months, and Torstenâs OSWindow uses it. >>> >>> Sorry then it is my fault. I know that Torsten already ported OSWindow to UFFI, and that most things are already working. >>> >>> UFFI provides FFIConstantHandle type to deal with windows HANDLE types, as comment says: >>> >>> I represent a constant HANDLE, as described in *Windows MSDN>https://msdn.microsoft.com/en-us/library/windows/desktop/ms724457(v=vs.85).… <https://msdn.microsoft.com/en-us/library/windows/desktop/ms724457(v=vs.85).…> >>> >>> A ==HANDLE== is a special kind of external object who is accessed through numbers, therefore and ==ExternalAddress== is not appropriate to describe it (since they are constants and external addresses represents disposable spaces from memory). >>> >>> Is not clear this is necessary outside Windows, but according to documentation they are somekind analogous to unix's File Descriptors (but with some remarkable diferences, as documented *here>http://lackingrhoticity.blogspot.fr/2015/05/passing-fds-handles-between-pro… <http://lackingrhoticity.blogspot.fr/2015/05/passing-fds-handles-between-pro…>. >>> >>> Example: >>> [[[ >>> HWND := #FFIConstantHandle. >>> self ffiCall: #(HWND GetActiveWindow()) >>> ]]] >>> >>> is there anything Iâm missing? >>> >>> I don't know what else should I do, I already posted the example. >>> The code I provided just don't work (DNU on isExternalAddress, see other mail), and I have no idea how to make it work. >>> Yes, maybe I don't know enough about ffi for this type of the function argument passing. >> >> the example is a simplification, you cannot put both definition and call in same methodâ¦ find attached a working example of what you want. >> >> >> Thank you! >> >> >> >> >> >>> >>> (actually I tried to port some NBOpenGL code to UFFI, for this I need to register a Window Class with WinWndClassEx (to create a gl context). >>> So if this *is* already working, I need to look what I have done wrong). >>> >>> thanks for your response. >>> nicolai >>> >>> >>> >>> Esteban > >

June 24, 2016