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

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

by Esteban Lorenzano

Hi Nicolai, > On 25 Apr 2016, at 09:14, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-04-24 15:26 GMT+02:00 Torsten Bergmann <astares(a)gmx.de <mailto:astares@gmx.de>>: > Hi Nicolai, > > missed this thread - sorry. To my knowledge there was a call in NB for CreateWindow > but there was no example in opening a new window. For X-Windows there was an example > if I remember correctly. > > Hi Torsten, > > yes there is an "example" in NBOpenGL. On Windows, it registers and creates window for getting an opengl context. > The code and classes for registering and creating a window are similiar to what is now in your os-windows. > I needed to define some more pool variables for some style attributes, all that is working. > What did not work is storing the hInstance attribute in the WndClass struct. what and how it does not work? can you paste the code? cheers! Esteban > With NBOpenGL (and non-spur resp. NativeBoost) this works. > With the new UnifiedFFI this gives an error from: > > pointerAt: byteOffset put: value > "Store a pointer object at the given byte address" > value isExternalAddress > > > > Basically I would like to add support for this into OS-Windows, yes. > Some parts are there and UFFI now has easy callbacks. Havent looked > at OSWindow yet - but I guess the goal is to create native windows as well. > Also I would like to add more support in manipulating/quering other > external windows (which can be done using the already built in support > for process and window handles). > > In Win32 to create a window one has to register a window class first and > use the window class name afterwards in the CreateWindow API function. > > No time to look into this this week ... but can give a try afterwards. > The WNDCLASS/WNDCLASSEX structure needs to be wrapped, RegisterClass > called and CreateWindowEx with a callback for a function to process > window messages. > > Dont know how if this interferes with the VM's own processing loop ... > but we should give a try. If you catch me on Slack next week we can > try together. > > Bye > Torsten > > > Gesendet: Sonntag, 24. April 2016 um 12:17 Uhr > Von: "Nicolai Hess" <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> > Betreff: Re: [Pharo-dev] OS-Windows and UnifiedFFI > > > > 2016-04-15 21:58 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>>: > > Hi Torsten, Esteban, > I try to use OS-Windows (not OSWindow :) ) with latest spur VM and UnifiedFFI.As far as I can see, you (Torsten) already ported some parts to UnifiedFFI - great, thanks! > I now try to open a new window withWinWindow>>createWindowEx ....as I took this example originally from NBOpenGL, it seems I have to define > a Window Class first, with > WinWndClassEx > This seems to work in the old NBOpenGL/NBWin32 code but not with OS-Windows > WinWndClassEx > first, NBOpenGL uses > NativeBoostWin32 getVMModuleHandle for an HModule instance > there is a similar call in OS-Windows, WinProcess getVMModuleHandle > (I needed to define a missing type, HMODULE, but that works). > > What does not work is this part: > > | hInst wndClass | > hInst := WinProcess getVMModuleHandle. > wndClass := WinWndClassEx new. > wndClass hInstance: hInst. > > FF complains about > pointerAt: byteOffset put: value > "Store a pointer object at the given byte address" > value isExternalAddress > > here value is not a handle, but a small integer, and it does not define isExternalAddress > > I tried to put the handle instead of the handles value, but this does not work either. > > Any Idea what is missing here, I need a way to store the HMODULE handle > in the structure of the WinWNdClassEx > > Thanks in advance. > > Anyone? > >

April 25, 2016

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

by Nicolai Hess

2016-04-24 15:26 GMT+02:00 Torsten Bergmann <astares(a)gmx.de>: > Hi Nicolai, > > missed this thread - sorry. To my knowledge there was a call in NB for > CreateWindow > but there was no example in opening a new window. For X-Windows there was > an example > if I remember correctly. > Hi Torsten, yes there is an "example" in NBOpenGL. On Windows, it registers and creates window for getting an opengl context. The code and classes for registering and creating a window are similiar to what is now in your os-windows. I needed to define some more pool variables for some style attributes, all that is working. What did not work is storing the hInstance attribute in the WndClass struct. With NBOpenGL (and non-spur resp. NativeBoost) this works. With the new UnifiedFFI this gives an error from: pointerAt: byteOffset put: value "Store a pointer object at the given byte address" value isExternalAddress > > Basically I would like to add support for this into OS-Windows, yes. > Some parts are there and UFFI now has easy callbacks. Havent looked > at OSWindow yet - but I guess the goal is to create native windows as well. > Also I would like to add more support in manipulating/quering other > external windows (which can be done using the already built in support > for process and window handles). > > In Win32 to create a window one has to register a window class first and > use the window class name afterwards in the CreateWindow API function. > > No time to look into this this week ... but can give a try afterwards. > The WNDCLASS/WNDCLASSEX structure needs to be wrapped, RegisterClass > called and CreateWindowEx with a callback for a function to process > window messages. > > Dont know how if this interferes with the VM's own processing loop ... > but we should give a try. If you catch me on Slack next week we can > try together. > > Bye > Torsten > > > Gesendet: Sonntag, 24. April 2016 um 12:17 Uhr > Von: "Nicolai Hess" <nicolaihess(a)gmail.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] OS-Windows and UnifiedFFI > > > > 2016-04-15 21:58 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > Hi Torsten, Esteban, > I try to use OS-Windows (not OSWindow :) ) with latest spur VM and > UnifiedFFI.As far as I can see, you (Torsten) already ported some parts to > UnifiedFFI - great, thanks! > I now try to open a new window withWinWindow>>createWindowEx ....as I > took this example originally from NBOpenGL, it seems I have to define > a Window Class first, with > WinWndClassEx > This seems to work in the old NBOpenGL/NBWin32 code but not with OS-Windows > WinWndClassEx > first, NBOpenGL uses > NativeBoostWin32 getVMModuleHandle for an HModule instance > there is a similar call in OS-Windows, WinProcess getVMModuleHandle > (I needed to define a missing type, HMODULE, but that works). > > What does not work is this part: > > | hInst wndClass | > hInst := WinProcess getVMModuleHandle. > wndClass := WinWndClassEx new. > wndClass hInstance: hInst. > > FF complains about > pointerAt: byteOffset put: value > "Store a pointer object at the given byte address" > value isExternalAddress > > here value is not a handle, but a small integer, and it does not define > isExternalAddress > > I tried to put the handle instead of the handles value, but this does not > work either. > > Any Idea what is missing here, I need a way to store the HMODULE handle > in the structure of the WinWNdClassEx > > Thanks in advance. > > Anyone? > >

April 25, 2016

Re: [Pharo-dev] [Pharo 5] Symbol #'distance_2pts' not accepted at package installation

by Serge Stinckwich

On Mon, Apr 25, 2016 at 10:19 AM, Ben Coman <btc(a)openinworld.com> wrote: > On Mon, Apr 25, 2016 at 4:03 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: >> On 24-04-16 21:35, stepharo wrote: >>> >>> >>> >>> Le 24/4/16 Ã 12:10, Hilaire a Ã©crit : >>>> >>>> Hi Nicolai, >>>> >>>> http://smalltalkhub.com/#!/~HilaireFernandes/DrGeo >>>> >>>> You can't use the installation procedure described in the wiki, because >>>> Pharo5 also got stuck when loading a dependent package (gettext package >>>> to name it). >>> >>> From where do you load gettext because I can have a look. >>> Your work is important to me :) >> >> >> It is a simple, but annoying problem. A symbol with whitespace between the >> # and the literal is no longer accepted by RBScanner>scanLiteral > > That seems a bad regression, to break loading code that > loads fine with Pharo 4, and could be a common scenario. > >> >> scanLiteral >> "Do not allow whitespace between # and the literal." >> >> "Do not allow number literals after the #" >> >> self step. >> characterType = #alphabetic >> ifTrue: [ ^ self scanSymbol ]. >> characterType = #binary >> ifTrue: >> [ ^ (self scanBinary: RBLiteralToken) >> stop: self previousStepPosition ]. >> currentCharacter = $' >> ifTrue: [ ^ self scanStringSymbol ]. >> (currentCharacter = $( or: [ currentCharacter = $[ ]) >> ifTrue: [ ^ self scanLiteralArrayToken ]. >> "Accept multiple #." >> currentCharacter = $# >> ifTrue: [ ^ self scanLiteral ]. >> ^ self scanError: 'Expecting a literal type' >> >> vs >> >> scanLiteral >> self step. >> self stripSeparators. >> characterType = #alphabetic >> ifTrue: [ ^ self scanSymbol ]. >> characterType = #binary >> ifTrue: [ ^ (self scanBinary: RBLiteralToken) stop: self >> previousStepPosition ]. >> currentCharacter = $' >> ifTrue: [ ^ self scanStringSymbol ]. >> (currentCharacter = $( or: [ currentCharacter = $[ ]) >> ifTrue: [ ^ self scanLiteralArrayToken]. >> "Accept some strange literals like '#1', '# species' and '##species:'" >> characterType = #digit >> ifTrue: [ ^ self scanNumber ]. >> currentCharacter = $# >> ifTrue: [ ^ self scanLiteral ]. >> ^self scanError: 'Expecting a literal type' translated. >> >> The problem is that recovering from that while loading code asks for >> rather well-developed debugging skills... It is faster to just load the code >> in an old Pharo image, fix it there and commit a new version > > Wouldn't you then have the problem of manually tracking down > that space in your codebase ? > > Is it feasible to have a setting for compatibility so old code can at > least be loaded in Pharo 5? Then a re-compilation with setting > disabled would directly identify the error to be fixed. Maybe even > Monticello could always temporarily enable the setting while loading - > with that behaviour removed for Pharo 6. Normally there is already a setting to use the old parser. I have done something similar recently in order to load old code, I just switch the setting before loading my old code and then fix the code. Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

April 25, 2016

Re: [Pharo-dev] [Pharo 5] Symbol #'distance_2pts' not accepted at package installation

by Ben Coman

On Mon, Apr 25, 2016 at 4:03 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > On 24-04-16 21:35, stepharo wrote: >> >> >> >> Le 24/4/16 Ã 12:10, Hilaire a Ã©crit : >>> >>> Hi Nicolai, >>> >>> http://smalltalkhub.com/#!/~HilaireFernandes/DrGeo >>> >>> You can't use the installation procedure described in the wiki, because >>> Pharo5 also got stuck when loading a dependent package (gettext package >>> to name it). >> >> From where do you load gettext because I can have a look. >> Your work is important to me :) > > > It is a simple, but annoying problem. A symbol with whitespace between the > # and the literal is no longer accepted by RBScanner>scanLiteral That seems a bad regression, to break loading code that loads fine with Pharo 4, and could be a common scenario. > > scanLiteral > "Do not allow whitespace between # and the literal." > > "Do not allow number literals after the #" > > self step. > characterType = #alphabetic > ifTrue: [ ^ self scanSymbol ]. > characterType = #binary > ifTrue: > [ ^ (self scanBinary: RBLiteralToken) > stop: self previousStepPosition ]. > currentCharacter = $' > ifTrue: [ ^ self scanStringSymbol ]. > (currentCharacter = $( or: [ currentCharacter = $[ ]) > ifTrue: [ ^ self scanLiteralArrayToken ]. > "Accept multiple #." > currentCharacter = $# > ifTrue: [ ^ self scanLiteral ]. > ^ self scanError: 'Expecting a literal type' > > vs > > scanLiteral > self step. > self stripSeparators. > characterType = #alphabetic > ifTrue: [ ^ self scanSymbol ]. > characterType = #binary > ifTrue: [ ^ (self scanBinary: RBLiteralToken) stop: self > previousStepPosition ]. > currentCharacter = $' > ifTrue: [ ^ self scanStringSymbol ]. > (currentCharacter = $( or: [ currentCharacter = $[ ]) > ifTrue: [ ^ self scanLiteralArrayToken]. > "Accept some strange literals like '#1', '# species' and '##species:'" > characterType = #digit > ifTrue: [ ^ self scanNumber ]. > currentCharacter = $# > ifTrue: [ ^ self scanLiteral ]. > ^self scanError: 'Expecting a literal type' translated. > > The problem is that recovering from that while loading code asks for > rather well-developed debugging skills... It is faster to just load the code > in an old Pharo image, fix it there and commit a new version Wouldn't you then have the problem of manually tracking down that space in your codebase ? Is it feasible to have a setting for compatibility so old code can at least be loaded in Pharo 5? Then a re-compilation with setting disabled would directly identify the error to be fixed. Maybe even Monticello could always temporarily enable the setting while loading - with that behaviour removed for Pharo 6. cheers -ben

April 25, 2016

Re: [Pharo-dev] [Pharo 5] Symbol #'distance_2pts' not accepted at package installation

by Stephan Eggermont

On 24-04-16 21:35, stepharo wrote: > > > Le 24/4/16 Ã 12:10, Hilaire a Ã©crit : >> Hi Nicolai, >> >> http://smalltalkhub.com/#!/~HilaireFernandes/DrGeo >> >> You can't use the installation procedure described in the wiki, because >> Pharo5 also got stuck when loading a dependent package (gettext package >> to name it). > From where do you load gettext because I can have a look. > Your work is important to me :) It is a simple, but annoying problem. A symbol with whitespace between the # and the literal is no longer accepted by RBScanner>scanLiteral scanLiteral "Do not allow whitespace between # and the literal." "Do not allow number literals after the #" self step. characterType = #alphabetic ifTrue: [ ^ self scanSymbol ]. characterType = #binary ifTrue: [ ^ (self scanBinary: RBLiteralToken) stop: self previousStepPosition ]. currentCharacter = $' ifTrue: [ ^ self scanStringSymbol ]. (currentCharacter = $( or: [ currentCharacter = $[ ]) ifTrue: [ ^ self scanLiteralArrayToken ]. "Accept multiple #." currentCharacter = $# ifTrue: [ ^ self scanLiteral ]. ^ self scanError: 'Expecting a literal type' vs scanLiteral self step. self stripSeparators. characterType = #alphabetic ifTrue: [ ^ self scanSymbol ]. characterType = #binary ifTrue: [ ^ (self scanBinary: RBLiteralToken) stop: self previousStepPosition ]. currentCharacter = $' ifTrue: [ ^ self scanStringSymbol ]. (currentCharacter = $( or: [ currentCharacter = $[ ]) ifTrue: [ ^ self scanLiteralArrayToken]. "Accept some strange literals like '#1', '# species' and '##species:'" characterType = #digit ifTrue: [ ^ self scanNumber ]. currentCharacter = $# ifTrue: [ ^ self scanLiteral ]. ^self scanError: 'Expecting a literal type' translated. The problem is that recovering from that while loading code asks for rather well-developed debugging skills... It is faster to just load the code in an old Pharo image, fix it there and commit a new version Stephan

April 24, 2016

Re: [Pharo-dev] [Pharo 5] Symbol #'distance_2pts' not accepted at package installation

by stepharo

Le 24/4/16 Ã 12:10, Hilaire a Ã©crit : > Hi Nicolai, > > http://smalltalkhub.com/#!/~HilaireFernandes/DrGeo > > You can't use the installation procedure described in the wiki, because > Pharo5 also got stuck when loading a dependent package (gettext package > to name it). From where do you load gettext because I can have a look. Your work is important to me :) Stef > You should manually load the DrGeoII-Core package, then DrGeoII-Polymoprh > > The problem occurs when loading DrGeoII-Core. > > Hilaire > > > > Le 24/04/2016 11:41, Nicolai Hess a Ã©crit : >> Hi Hilaire, >> >> can you point me to the repository where this DrGeo package is. >> >>

April 24, 2016

Re: [Pharo-dev] [Pharo 5] Locale broken

by stepharo

thanks for the feedback Le 24/4/16 Ã 19:40, Hilaire a Ã©crit : > https://pharo.fogbugz.com/f/cases/18076/Locale-broken

April 24, 2016

[Pharo 5] Locale broken

by Hilaire

https://pharo.fogbugz.com/f/cases/18076/Locale-broken -- Dr. Geo http://drgeo.eu

April 24, 2016

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

by Torsten Bergmann

Hi Nicolai, missed this thread - sorry. To my knowledge there was a call in NB for CreateWindow but there was no example in opening a new window. For X-Windows there was an example if I remember correctly. Basically I would like to add support for this into OS-Windows, yes. Some parts are there and UFFI now has easy callbacks. Havent looked at OSWindow yet - but I guess the goal is to create native windows as well. Also I would like to add more support in manipulating/quering other external windows (which can be done using the already built in support for process and window handles). In Win32 to create a window one has to register a window class first and use the window class name afterwards in the CreateWindow API function. No time to look into this this week ... but can give a try afterwards. The WNDCLASS/WNDCLASSEX structure needs to be wrapped, RegisterClass called and CreateWindowEx with a callback for a function to process window messages. Dont know how if this interferes with the VM's own processing loop ... but we should give a try. If you catch me on Slack next week we can try together. Â Bye Torsten Â Gesendet:Â Sonntag, 24. April 2016 um 12:17 Uhr Von:Â "Nicolai Hess" <nicolaihess(a)gmail.com> An:Â "Pharo Development List" <pharo-dev(a)lists.pharo.org> Betreff:Â Re: [Pharo-dev] OS-Windows and UnifiedFFI Â Â 2016-04-15 21:58 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: Hi Torsten, Esteban, Â I try to use OS-Windows (not OSWindow :) ) with latest spur VM and UnifiedFFI.As far as I can see, you (Torsten) already ported some parts to UnifiedFFI - great, thanks! Â I now try to open a new window withWinWindow>>createWindowEx ....as I took this example originally from NBOpenGL, it seems I have to define a Window Class first, with WinWndClassEx This seems to work in the old NBOpenGL/NBWin32 code but not with OS-Windows WinWndClassEx first, NBOpenGL uses NativeBoostWin32 getVMModuleHandle for an HModule instance there is a similar call in OS-Windows, WinProcess getVMModuleHandle (I needed to define a missing type, HMODULE, but that works). Â What does not work is this part: | hInst wndClass | Â Â Â hInst := WinProcess getVMModuleHandle. Â Â Â wndClass := WinWndClassEx new. Â Â Â wndClass hInstance: hInst. Â FF complains about pointerAt: byteOffset put: value Â Â Â "Store a pointer object at the given byte address" Â Â Â value isExternalAddress Â here value is not a handle, but a small integer, and it does not define isExternalAddress Â I tried to put the handle instead of the handles value, but this does not work either. Â Any Idea what is missing here, I need a way to store the HMODULE handle in the structure of the WinWNdClassEx Â Thanks in advance. Â Anyone?

April 24, 2016

[pharo-project/pharo-core]

by GitHub

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

April 24, 2016