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

[pharo-project/pharo-core] d93829: 60110

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: d938291183988224940621c636ddf2f55c792165 https://github.com/pharo-project/pharo-core/commit/d938291183988224940621c6… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-24 (Fri, 24 Jun 2016) Changed paths: M AST-Core.package/RBParseErrorNode.class/instance/converting/asSyntaxErrorNotification.st A Collections-Strings.package/String.class/instance/copying/trimLineSpaces.st A Collections-Tests.package/StringTest.class/instance/testing - converting/testTrimLineSpaces.st M Epicea.package/extension/CompiledMethod/instance/asEpiceaRingDefinition.st M Kernel.package/Halt.class/class/halting/onCount_.st M Kernel.package/Halt.class/class/halting/once.st M Kernel.package/Halt.class/class/private/haltIfBlockWithCallingObject_.st M Kernel.package/Halt.class/class/private/haltIfCallChainContains_.st M Kernel.package/Object.class/instance/deprecation/deprecated_transformWith_.st A OpalCompiler-Core.package/AbstractCompiler.class/class/settings/compileWithErrors.st A OpalCompiler-Core.package/AbstractCompiler.class/class/settings/compileWithErrors_.st M OpalCompiler-Core.package/AbstractCompiler.class/class/settings/compilerSettingsOn_.st M OpalCompiler-Core.package/CCompilationContext.class/class/instance creation/default.st M OpalCompiler-Core.package/CompilationContext.class/class/instance creation/default.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60109.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60110.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60109.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60110.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60110 18586 add String>>#trimmLineSpaces https://pharo.fogbugz.com/f/cases/18586 18591 fix call to #name in asEpiceaRingDefinition https://pharo.fogbugz.com/f/cases/18591 18583 For experiments: Option to compile with syntax errors https://pharo.fogbugz.com/f/cases/18583 18585 deprecated:transformWith: should to Transcript output https://pharo.fogbugz.com/f/cases/18585 http://files.pharo.org/image/60/60110.zip

June 24, 2016

Re: [Pharo-dev] Reordering working directory mess

by Yuriy Tymchuk

play-cache contains history from default playground. play-stash contains state of playground pages (if you rename "playgroundâ tab into something else it becomes a custom page. You can look it up with spotter) Uko > On 23 Jun 2016, at 22:18, stepharo <stepharo(a)free.fr> wrote: > > What is the difference between play-cache play-stash > > 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 >> > >

June 24, 2016

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

by Nicolai Hess

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. (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

> On 24 Jun 2016, at 09:26, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-05-30 14:59 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>>: > > > 2016-05-19 8:56 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>>: > > > 2016-04-25 10:17 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>>: > > > 2016-04-25 9:28 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > Hi Nicolai, > >> On 25 Apr 2016, at 09:14, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@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? > > > 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 > > > Any more ideas? > > > From my observation, > > hInst := NativeBoostWin32 getVMModuleHandle. > > hInst is not considered an external object, or its handle is not an > ExternalAddress, although the object is a WinHandle that is a subclass > of FFIExernalReference :-( > > I am lost here, > any help appreciated. > > > Please. > > (I do undestand that a winhandle is only a number and not a external memory. > But how to handle this "handles" when passing to a external function ?) Iâm sorryâ¦ I do not understand. This is solved in UFFI since some months, and Torstenâs OSWindow uses it. 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? Esteban > > > > > > 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? >> >> > > > > >

June 24, 2016

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

by Nicolai Hess

2016-05-30 14:59 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2016-05-19 8:56 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > >> >> >> 2016-04-25 10:17 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> >>> >>> >>> 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 >>> >>> >> Any more ideas? >> > > > From my observation, > > hInst := NativeBoostWin32 getVMModuleHandle. > > hInst is not considered an external object, or its handle is not an > ExternalAddress, although the object is a WinHandle that is a subclass > of FFIExernalReference :-( > > I am lost here, > any help appreciated. > Please. (I do undestand that a winhandle is only a number and not a external memory. But how to handle this "handles" when passing to a external function ?) > > >> >> >>> >>> >>>> >>>> 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? >>>>> >>>>> >>>> >>>> >>> >> >

June 24, 2016

Re: [Pharo-dev] senders seems broken

by Marcus Denker

This should be fixed in 60108. 18569 Finder search selector : Object>>name deprecation warning Marcus > On 23 Jun 2016, at 22:25, stepharo <stepharo(a)free.fr> wrote: > > for me the finder dropbox did not work at all. > > > > Le 22/6/16 Ã 16:23, Nicolai Hess a Ã©crit : >> broken, or a deprecation warning >> >> 2016-06-22 16:14 GMT+02:00 stepharo <stepharo(a)free.fr>: >> Ok >> >> I'm in the train so I will not try to download it :) >> >> The finder is broken. We cannot use the dropdown. >> >> Do you know if it was fixed too. >> >> >> Setf >> >> >> Le 22/6/16 Ã 16:02, Marcus Denker a Ã©crit : >> >> There where bugs but they should be fixed in the latest version. >> >> (in 60105 it works for me again). >> >> On 22 Jun 2016, at 15:53, stepharo <stepharo(a)free.fr> wrote: >> >> Hi marcus >> >> can you browse senders? Because I cannot anymore. >> >> Stef >> >> >> >> >> >> >> >

June 24, 2016

Re: [Pharo-dev] pharo 5 segfault (stack size?) [FreeBSD]

by Ben Coman

You could build a debug VM from here https://github.com/pharo-project/pharo-vm I also glimpsed some FreeBSD build options there you might try. cheers -ben On Fri, Jun 24, 2016 at 12:05 PM, Petr Fischer <petr.fischer(a)me.com> wrote: > So... I compiled latest sources (blessed) on CentOS 6.8, fine, moved > compiled binaries to FreeBSD and tried to load Seaside to the latest 50760 > image. > Still stack errors, log here: http://pastebin.com/raw/bf1EpWNt > > When I run this on CentOS, everything is fine (loading Seaside, no stack > errors), but when I run the same on FreeBSD, stack errors (segfaults) > occurs. > > So... There is something bad on FreeBSD side? Can I debug more? > > pf > > > > Try 50760 from... > > http://files.pharo.org/image/50/ > > > > cheers -ben > > > > On Sat, Jun 18, 2016 at 12:49 AM, Petr Fischer <petr.fischer(a)me.com> > wrote: > > > VM version (from > https://swing.fit.cvut.cz/jenkins/job/pharo-vm-spur-swing/) > > > > > > 5.0 #1 Sun Jan 17 14:19:14 CET 2016 gcc 4.7.2 [Production Spur ITHB VM] > > > CoInterpreter VMMaker.oscog-eem.1630 uuid: > 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 17 2016 > > > StackToRegisterMappingCogit VMMaker.oscog-eem.1630 uuid: > 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 17 2016 > > > https://github.com/estebanlm/pharo-vm.git Commit: > 21ec004cce7d26010c18d357c805a0e1a4ffe376 Date: 2016-01-14 11:42:33 +0100 > By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #498 > > > Linux swing-hudson-lin64 3.2.0-4-amd64 #1 SMP Debian 3.2.73-2+deb7u2 > x86_64 GNU/Linux > > > plugin path: /usr/home/pf/Work/Smalltalk/pharo5.0.centos/bin [default: > /usr/home/pf/Work/Smalltalk/pharo5.0.centos/bin/] > > > > > > Image version (from official 5.0 download): > > > > > > [version] 5.0 #50723 > > > > > > pf > > > > > >> in fact, this is not related to FFIâ¦ but it should be fixedâ¦ > > >> > > >> along with the VM version, which version of Pharo are you using? > > >> > > >> Esteban > > >> > > >> > On 17 Jun 2016, at 14:04, Max Leske <maxleske(a)gmail.com> wrote: > > >> > > > >> > Hi Petr, > > >> > > > >> > That looks like a bug with FreeType with our FFI. It should > actually have been fixed but I donât know if the VM for FreeBSD is up to > date. Can you post the output of âSmalltalk vm versionâ? > > >> > > > >> > Cheers, > > >> > Max > > >> > > > >> >> On 17 Jun 2016, at 13:26, Petr Fischer <petr.fischer(a)me.com> > wrote: > > >> >> > > >> >> Hello, I got some random segfaults (while loading Seaside) with 32 > bit spur vm on FreeBSD - can someone (with low level knowledge) decode > attached log? > > >> >> Is this some problem with stack size? Can I fix this? > > >> >> > > >> >> Log: > > >> >> http://pastebin.com/raw/NpFUnjh0 > > >> >> > > >> >> There is "**StackOverflow**" lines n the log... > > >> >> > > >> >> Thanks! pf > > >> >> > > >> > > > >> > > > >> > > >> > > > > > > >

June 24, 2016

Re: [Pharo-dev] pharo 5 segfault (stack size?) [FreeBSD]

by Petr Fischer

So... I compiled latest sources (blessed) on CentOS 6.8, fine, moved compiled binaries to FreeBSD and tried to load Seaside to the latest 50760 image. Still stack errors, log here: http://pastebin.com/raw/bf1EpWNt When I run this on CentOS, everything is fine (loading Seaside, no stack errors), but when I run the same on FreeBSD, stack errors (segfaults) occurs. So... There is something bad on FreeBSD side? Can I debug more? pf > Try 50760 from... > http://files.pharo.org/image/50/ > > cheers -ben > > On Sat, Jun 18, 2016 at 12:49 AM, Petr Fischer <petr.fischer(a)me.com> wrote: > > VM version (from https://swing.fit.cvut.cz/jenkins/job/pharo-vm-spur-swing/) > > > > 5.0 #1 Sun Jan 17 14:19:14 CET 2016 gcc 4.7.2 [Production Spur ITHB VM] > > CoInterpreter VMMaker.oscog-eem.1630 uuid: 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 17 2016 > > StackToRegisterMappingCogit VMMaker.oscog-eem.1630 uuid: 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 17 2016 > > https://github.com/estebanlm/pharo-vm.git Commit: 21ec004cce7d26010c18d357c805a0e1a4ffe376 Date: 2016-01-14 11:42:33 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #498 > > Linux swing-hudson-lin64 3.2.0-4-amd64 #1 SMP Debian 3.2.73-2+deb7u2 x86_64 GNU/Linux > > plugin path: /usr/home/pf/Work/Smalltalk/pharo5.0.centos/bin [default: /usr/home/pf/Work/Smalltalk/pharo5.0.centos/bin/] > > > > Image version (from official 5.0 download): > > > > [version] 5.0 #50723 > > > > pf > > > >> in fact, this is not related to FFIâ¦ but it should be fixedâ¦ > >> > >> along with the VM version, which version of Pharo are you using? > >> > >> Esteban > >> > >> > On 17 Jun 2016, at 14:04, Max Leske <maxleske(a)gmail.com> wrote: > >> > > >> > Hi Petr, > >> > > >> > That looks like a bug with FreeType with our FFI. It should actually have been fixed but I donât know if the VM for FreeBSD is up to date. Can you post the output of âSmalltalk vm versionâ? > >> > > >> > Cheers, > >> > Max > >> > > >> >> On 17 Jun 2016, at 13:26, Petr Fischer <petr.fischer(a)me.com> wrote: > >> >> > >> >> Hello, I got some random segfaults (while loading Seaside) with 32 bit spur vm on FreeBSD - can someone (with low level knowledge) decode attached log? > >> >> Is this some problem with stack size? Can I fix this? > >> >> > >> >> Log: > >> >> http://pastebin.com/raw/NpFUnjh0 > >> >> > >> >> There is "**StackOverflow**" lines n the log... > >> >> > >> >> Thanks! pf > >> >> > >> > > >> > > >> > >> > > >

June 24, 2016

Re: [Pharo-dev] Reordering working directory mess

by Ben Coman

On Fri, Jun 24, 2016 at 4:21 AM, Nicolas Anquetil <nicolas.anquetil(a)inria.fr > wrote: > and why not put Pharo.changes in ./pharo while we are at it ? > too difficult? > The same thought crossed my mind for a moment, but the two files are *tightly* coupled. If the .changes file wasn't sitting there right next to the .image file, many newcomers will forget to copy them together - and even for the rest of us, its more pain to select two files in different directories and copy them to two other directories, than if they are together. cheers -ben > > nicolas > > > On 23/06/2016 22:18, stepharo wrote: > >> What is the difference between play-cache play-stash >> >> 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 >>> >>> >> >> > -- > Nicolas Anquetil > RMod team -- Inria Lille > > >

June 24, 2016

GemStone/S 3.3.1 released

by Richard Sargent

Dear GemTalk Customers, We are pleased to announce the release of GemStone/S 64 Bit 3.3.1, a maintenance release providing a number of important features and bug fixes, including support for handling ICU library version changes over upgrade. We encourage all GemStone/S customers to upgrade to this release. Downloads and documentation for this release can be found at the following URL: http://gemtalksystems.com/products/gs64/ This server release includes the latest Visual Statistics Display (VSD) release, version 5.2, with new features and fixes in particular for working with multiple files. Documentation and VSD-only downloads, e.g. for platforms other than your server, can be found at the following URL: http://gemtalksystems.com/products/vsd/ Please contact GemTalk technical support if you have any trouble downloading or upgrading. Thank you! Note that GemStone/S ships with a free-even-for-commercial-use license. -- View this message in context: http://forum.world.st/GemStone-S-3-3-1-released-tp4902747.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 23, 2016