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

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

by Esteban Lorenzano

> 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). well, that I donât knowâ¦ for me it works, I tested it in Win10 and it was fine. What exactly are you trying to do? Esteban > > > >> 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

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

by Nicolai Hess

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). > > 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] Reordering working directory mess

by Esteban Lorenzano

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. 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> 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 Esteban Lorenzano

â¦ and I enhanced the example to not induce to confusion anymore :) 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 <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

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

by Nicolai Hess

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

[pharo-project/pharo-core] b67123: 60111

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: b67123481cfacd8b11c33802fdacc9fc7d182137 https://github.com/pharo-project/pharo-core/commit/b67123481cfacd8b11c33802… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-24 (Fri, 24 Jun 2016) Changed paths: R Kernel.package/CompiledMethod.class/instance/literals/symbolLiterals.st M Kernel.package/CompiledMethod.class/instance/testing/containsHalt.st M Kernel.package/CompiledMethod.class/instance/testing/isDeprecated.st A Kernel.package/CompiledMethod.class/instance/testing/sendsAnySelectorOf_.st M Manifest-Core.package/TheManifestBuilder.class/definition.st M Manifest-Core.package/TheManifestBuilder.class/instance/printing/printOn_.st M Nautilus.package/MethodContainsFlagsAction.class/instance/order/isActionHandled.st M Nautilus.package/MethodWidget.class/instance/private/methodWrapper_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60110.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60111.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60110.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60111.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Inspector.package/EyeAbstractInspector.class/instance/menu/inspectionMenu_.st Log Message: ----------- 60111 18592 fix a #name deprecation in Manifest Builder https://pharo.fogbugz.com/f/cases/18592 18587 Show depreciated methods with strikethrough emphasis https://pharo.fogbugz.com/f/cases/18587 18584 DNU on showing menu in PointerExplorer https://pharo.fogbugz.com/f/cases/18584 http://files.pharo.org/image/60/60111.zip

June 24, 2016

[pharo-project/pharo-core]

by GitHub

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

June 24, 2016

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

by Esteban Lorenzano

> 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).… <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. > > (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] Reordering working directory mess

by Tudor Girba

Hi, > On Jun 23, 2016, at 10:18 PM, stepharo <stepharo(a)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 www.feenk.com "Every thing should have the right to be different."

June 24, 2016

[pharo-project/pharo-core]

by GitHub

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

June 24, 2016