- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] XMLParser changes

by Jan Vrany

Not sure whether this was an intention. but strictly speaking,Â new behavior is correct.Â See Extensible Markup Language (XML) 1.0 (Fifth Edition),Â SectionÂ 2.10 White Space Handling: "An XML processor must always pass all characters in a document that are not markup through to the application. A validating XML processor must also inform the application which of these characters constitute white space appearing in element content." Jan On Mon, 2016-04-25 at 12:14 +0200, Cyril Ferlicot Delbecque wrote: > Hi, > > last week there was a new stable version of XMLParser and some tests > broke in some tools. I think that there was a regression in this > version. > > Snippet: > > (XMLDOMParser parse: '<?xml version="1.0" encoding="UTF-8"?> >  > <Clones> > Â Â Â Â <ClonedFragment cloneName="test"> > Â Â Â Â Â Â Â Â <Member fileName="ProgramA"/> > Â Â Â Â Â Â Â Â <Member fileName="ProgramB"/> > Â Â Â Â </ClonedFragment> > Â Â Â Â <ClonedFragment cloneName="test2"> > Â Â Â Â Â Â Â Â <Member fileName="ProgramA"/> > Â Â Â Â Â Â Â Â <Member fileName="ProgramB"/> > Â Â Â Â </ClonedFragment> > </Clones>') elements first nodes > > With the release 2.7.4 we get 2 nodes but in release 2.7.6 we get 5 > nodes. The 2 previous ones and 3 empty String nodes. > > I think this is not what we expect. Correct me if I am wrong :) > >

April 25, 2016

[Pharo 5] Gettext

by Hilaire

I open a new topic. It looks there are some issues with Gettext. I saw Johan is working on it, may be he can tell us a bit more. The repo is here: MCSmalltalkhubRepository owner: 'PharoExtras' project: 'Gettext' user: '' password: '' Thanks Hilaire Le 24/04/2016 21:35, stepharo a Ã©crit : >> 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 :) -- Dr. Geo http://drgeo.eu

April 25, 2016

[Pharo 5] Some feedbacks

by Hilaire

Hi, While giving a try to Pharo5, I wrote some notes about how it fells. It may be useful to share it. Of course it is also very opinionated and may be rude. But no offense to consider, really. More time is need for a real developer experience, may be later. Hilaire -- Dr. Geo http://drgeo.eu

April 25, 2016

XMLParser changes

by Cyril Ferlicot Delbecque

Hi, last week there was a new stable version of XMLParser and some tests broke in some tools. I think that there was a regression in this version. Snippet: (XMLDOMParser parse: '<?xml version="1.0" encoding="UTF-8"?>  <Clones> <ClonedFragment cloneName="test"> <Member fileName="ProgramA"/> <Member fileName="ProgramB"/> </ClonedFragment> <ClonedFragment cloneName="test2"> <Member fileName="ProgramA"/> <Member fileName="ProgramB"/> </ClonedFragment> </Clones>') elements first nodes With the release 2.7.4 we get 2 nodes but in release 2.7.6 we get 5 nodes. The 2 previous ones and 3 empty String nodes. I think this is not what we expect. Correct me if I am wrong :) -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

April 25, 2016

Re: [Pharo-dev] Collection with spatiotemporal indexation - Ideas and discussions ?

by CÃ©drick BÃ©ler

Hi Robert, > > Have you considered seeing if there are any Voronoi diagram packages in one of the repositories? I believe there is a fair bit of research into algorithms. You search use of spaciotemporal collated data sounds very interesting and there is a segment on computation over segments in this slide deck, that might be something, I don't know: http://graphics.stanford.edu/courses/cs368-06-spring/handouts/Delaunay_2.pdf. Certainly there is utility on the graphics side to use a 4D quadratic model (with GPU accel) and may well be modeled already in squeak/Pharo. Would't that be something! Thanks for the links, very interesting read. Iâll have a closer look if I need to develop proper algorithms. Cheers, CÃ©drik > > > Regards, > Robert > > > On 04/23/2016 01:29 PM, CÃ©drick BÃ©ler wrote: >> Hi Esteban, >> >> Thanks a lot, I think Iâll try your History package, it seems to be a very good starting point (instead of hacking it myself). >> Iâll try it soon. >> >> Thanks for all the information ;) >> >> Cheers, >> >> CÃ©drik >> >> >>> Le 23 avr. 2016 Ã 18:28, Esteban A. Maringolo <emaringolo(a)gmail.com> a Ã©crit : >>> >>> Maybe instead of having a Dictionary, you can use my History package [1]. >>> It allows you to add elements to "the history", and the History class >>> will provide certain "lookup" strategies depending on how you want to >>> query it. >>> >>> It is a trimmed down version of an utility class I used for years in >>> commercial products where the History contained thousands of elements. >>> This version uses linear search, my previous implementation used >>> binary search which was significantly faster with lots of elements in >>> the collection. >>> >>> Of course it doesn't solve your spatial queries needs, I don't know if >>> there is something in Smalltalk for that other than the distance >>> between two coordinates[2], PostgreSQL 9.2 has some support for >>> "temporal" data/tables which you could combine with PostGIS if you >>> need to combine a spatial query with a temporal one [3]. >>> >>> Regards, >>> >>> [1] http://www.smalltalkhub.com/#!/~emaringolo/History >>> [2] http://pastebin.com/ThKDXCKK >>> [3] http://clarkdave.net/2015/02/historical-records-with-postgresql-and-tempora… >>> Esteban A. Maringolo >>> >>> >>> 2016-04-23 12:13 GMT-03:00 CÃ©drick BÃ©ler <cdrick65(a)gmail.com>: >>>> >>>> Sure, but 1) that's not a lot >>>> >>>> 2) do you even know if you need interactive stuff or if batch processing is >>>> ok? >>>> >>>> >>>> interactive I would sayâ¦ but hard to be certain right now as it depends on >>>> design choicesâ¦ do we cache ? do we aggregate past data ? extra indexes ? >>>> Iâll see later. >>>> I want something simple, keep everythingâ¦ and query according to time >>>> interval, areas (contexts)â¦ >>>> >>>> But yes for now this is pointless to look for something optimal and Iâll use >>>> a dictionary as it will be small at start. >>>> >>>> Cheers, >>>> >>>> CÃ©drik >>>> >>>> >>>> >>>> >>>> -- >>>> Damien Pollet >>>> type less, do more [ | ] http://people.untyped.org/damien.pollet >>>> >>>> >> > > -- > Robert > . .. ... ^,^ > >

April 25, 2016

Re: [Pharo-dev] Collection with spatiotemporal indexation - Ideas and discussions ?

by CÃ©drick BÃ©ler

> > My impression was that the Geolocation & Spatiotemperal classes already > exist (and presumably are already packaged), I donât think so but if you know some packages, please tell me :) > so I was thinking of the > collection class (which would have the geolocation and spatiotemperal as > dependencies). > >> I can try something but I think this will deserve more Â« computational >> thinking Â» power than I have ^^ > > Me too, but having something is still better than nothing, and maybe > someone will provide ideas for improvements. > Iâll see what Iâll come up with and Iâll publish them. Cheers, CÃ©drik > > Cheers, > Alistair > >

April 25, 2016

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

by Nicolai Hess

2016-04-25 9:28 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > 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>: > >> 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? > Sure. Load stable version of Torstens OSWindows. Change WinProcess class>>getVMModuleHandle (it has to use HINSTANCE instead of HMODULE (or just define a new pool variable HMODULE in WinTypes)) getVMModuleHandle "The GetModuleHandle function retrieves a module handle for the specified module if the file has been mapped into the address space of the calling process." ^ self ffiCall: #( HINSTANCE GetModuleHandleA (0)) module: #Kernel32 Now create a new WinWndClassEx and set the hInstance field: |hInst wndClass| hInst := WinProcess getVMModuleHandle. wndClass := WinWndClassEx new. wndClass hInstance: hInst. -> Message not understood SmallInteger>>isExternalAddress The equivalent code with NB that was working: |hInst wndClass| hInst := NativeBoostWin32 getVMModuleHandle. wndClass := NBWndClassEx new. wndClass hInstance: hInst. wndClass > > 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> >> 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] 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