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

Re: [Pharo-dev] Smalltalk ui icons vs iconNamed: vs @

by Henrik Nergaard

What about Symbol >>#asIcon ^ Smalltalk ui icons iconNamed: self Then one can do: "#add asIcon" ? Best regards, Henrik -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Peter Uhnak Sent: Monday, May 30, 2016 4:34 PM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: [Pharo-dev] Smalltalk ui icons vs iconNamed: vs @ Hi, My understanding is that now instead of Smalltalk ui icons smallConfigurationIcon I should do Smalltalk ui iconNamed: #smallConfigurationIcon This is however really unpractical, because it changes the operator priority, so I have to wrap it in parentheses every single time. Button new icon: (... iconNamed: ...) How about we add '@' or another binary selector so we can avoid the parentheses? Peter

May 30, 2016

Call for feedbacks: Enterprise Pharo ePub version

by Thibault ARLOING

Hi, I created an ePub version of the book Enterprise Pharo for electronic readers. It would be great if you could test it and give me feedbacks on everything that shocks you. You can downlod the file here<http://files.pharo.org/books-ressources/entreprise-pharo/>. Thanks, Thibault

May 30, 2016

Smalltalk ui icons vs iconNamed: vs @

by Peter Uhnak

Hi, My understanding is that now instead of Smalltalk ui icons smallConfigurationIcon I should do Smalltalk ui iconNamed: #smallConfigurationIcon This is however really unpractical, because it changes the operator priority, so I have to wrap it in parentheses every single time. Button new icon: (... iconNamed: ...) How about we add '@' or another binary selector so we can avoid the parentheses? Peter

May 30, 2016

[pharo-project/pharo-core]

by GitHub

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

May 30, 2016

[pharo-project/pharo-core] 0a9b12: 60046

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 0a9b1205f52b6a5b4b6014620ddc5a7d5261b254 https://github.com/pharo-project/pharo-core/commit/0a9b1205f52b6a5b4b601462… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-05-30 (Mon, 30 May 2016) Changed paths: A Kernel-Tests.package/ProcessSpecificTest.class/instance/testing/testInheritableVariable.st A Kernel-Tests.package/TestInheritableVariable.class/README.md A Kernel-Tests.package/TestInheritableVariable.class/class/controlling/disable.st A Kernel-Tests.package/TestInheritableVariable.class/class/controlling/enable.st A Kernel-Tests.package/TestInheritableVariable.class/class/testing/enabled.st A Kernel-Tests.package/TestInheritableVariable.class/class/testing/isInheritable.st A Kernel-Tests.package/TestInheritableVariable.class/definition.st M Kernel.package/Process.class/class/instance creation/forContext_priority_.st M Kernel.package/Process.class/class/process specific/allocatePSKey_.st A Kernel.package/Process.class/class/process specific/updateInheritableKeys.st M Kernel.package/Process.class/definition.st A Kernel.package/Process.class/instance/process specific/installEnvIntoForked_.st M Kernel.package/ProcessSpecificVariable.class/README.md A Kernel.package/ProcessSpecificVariable.class/class/testing/isInheritable.st A Kernel.package/ProcessSpecificVariable.class/instance/accessing/index.st A Kernel.package/ProcessSpecificVariable.class/instance/inheriting/installValue_intoForked_from_.st A Kernel.package/ProcessSpecificVariable.class/instance/inheriting/isInheritable.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60045.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60046.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60045.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60046.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60046 17742 inheritable process specific variables https://pharo.fogbugz.com/f/cases/17742 http://files.pharo.org/image/60/60046.zip

May 30, 2016

Re: [Pharo-dev] Problem with delay waiting (OSSubprocess code) on Pharo 5.0

by Mariano Martinez Peck

Hi Ben, I opened this issue for tracking the problem and not forget: https://pharo.fogbugz.com/f/cases/18359/Problem-with-DelayExperimentalSpinS… Cheers, On Fri, May 20, 2016 at 2:58 PM, Ben Coman <btc(a)openinworld.com> wrote: > On Sat, May 21, 2016 at 12:05 AM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: > > Ben, for the record, I am using DelayMillisecondScheduler for a day and a > > half and so far no problem. > > Cool. Thats why I left it there. I hope to soon have something for you > to try with the newer design. Thanks for the update. > > cheers -ben > > > On Thu, May 19, 2016 at 9:19 AM, Mariano Martinez Peck > > <marianopeck(a)gmail.com> wrote: > >> > >> > >> > >> On Wed, May 18, 2016 at 9:49 PM, Martin McClure <martin(a)hand2mouse.com> > >> wrote: > >>> > >>> On 05/18/2016 03:17 PM, Martin McClure wrote: > >>>> > >>>> On 05/18/2016 08:49 AM, Mariano Martinez Peck wrote: > >>>>> > >>>>> Hi guys, > >>>>> > >>>>> I am seeing a problem in Pharo 5.0 regarding Delay >> wait. I cannot > >>>>> explain how this could happened but it does, and it happened to me a > couple > >>>>> of times (but not fully reproducible). > >>>>> > >>>> > >>>> Hmm. The schedulerResumptionTime is, somehow, being (approximately) > >>>> doubled. It's not clear how that can happen, but I'll look a little > more. > >>>> > >>> > >>> Mario, is there any chance that you might be saving the image during > one > >>> of these Delays? > >>> > >>> > >>> This one smells like a race condition, and I think I see something that > >>> *might* explain it. But I don't have any more time to spend on this > one, so > >>> I'll leave the rest to someone else. I hope this is helpful: > >>> > >>> The only way I immediately see for the schedulerResumptionTime to > become > >>> approximately doubled is if the Delay's resumption time is adjusted by > >>> #restoreResumptionTimes without previously having been adjusted by > >>> #saveResumptionTimes. > >>> > >>> The only time either of those are sent, that I can see, is on saving > the > >>> image. Both are normally sent, (save before the snapshot, restore > >>> afterwards), but there may be a hole there. > >>> > >> > >> Martin, first off, thanks for the research!!! > >> > >> Now....your email made me remember something: I did get VM crash when > >> saving the image a couple of times. The VM crashed when saving the > image. If > >> I re-opened the image, it looks like if the image was indeed saved (so > the > >> snapshot primitive itself did work), but I suspect not all shutdown code > >> could have been run correctly. > >> > >> The VM crash looks like the FreeTypeFace >> pvtDestroyHandle which, as > >> far as I know, it's a "known crash" (I attach crash dump). From what I > can > >> see, if I follow all the stack, the crash starts from the WeakArray >> > >> startUp: . > >> That means that...depending on the order of the startup list...the > >> Scheduler may not have been run after the crash. > >> > >> Now.... WeakArray initialization does: > >> > >> SessionManager default > >> registerSystemClassNamed: self name. > >> While... > >> > >> Delay class >> startUp "Restart active delay, if any, when resuming a > >> snapshot." Scheduler startUp. > >> > >> And the Delay registration is > >> > >> SessionManager default > >> registerSystemClassNamed: self name > >> atPriority: 20. > >> > >> So...that seems correct... > >> > >> I can verify this by: > >> > >> SessionManager default systemCategory prioritizedList > >> > >> Anyway...not sure if this adds something, but just wanted to note this. > >> > >> > >>> > >>> #saveResumptionTimes is only sent (by this scheduler class) when the > >>> accessProtect semaphore is held, but #handleTimerEvent: is executed in > the > >>> timing Process *without* the protection of accessProtect, in the case > of the > >>> VM signaling the timingSemaphore. If the VM signals the > timingSemaphore, > >>> #handleTimerEvent: could run in the middle of #saveResumptionTimes. If > some > >>> Delay expires because of that timer event, our Delay could move from > being > >>> the first suspended delay to being the active delay. If that happens > after > >>> we've adjusted the active delay, but before we've processed the > suspended > >>> delays, that Delay will not get adjusted, and will show the symptoms > that > >>> Mariano is seeing. > >>> > >>> Also, I'm not sure how the Heap that holds the suspendedDelays will > react > >>> to being modified in the middle of an enumeration. That might open a > larger > >>> window for the problem. > >>> > >>> Regards, > >>> > >>> -Martin > >>> > >> > >> > >> > >> -- > >> Mariano > >> http://marianopeck.wordpress.com > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

May 30, 2016

[pharo-project/pharo-core]

by GitHub

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

May 30, 2016

[pharo-project/pharo-core] 101375: 60045

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 101375531239890a39930c4cb572f2b61f6ffdb7 https://github.com/pharo-project/pharo-core/commit/101375531239890a39930c4c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-05-30 (Mon, 30 May 2016) Changed paths: A Kernel-Tests.package/BlockClosureTest.class/instance/helpers/blockWithNonLocalReturn_.st A Kernel-Tests.package/BlockClosureTest.class/instance/tests - evaluating/testCannotReturn.st A Kernel-Tests.package/MethodContextTest.class/instance/tests/testCannotReturn.st M Kernel.package/BlockCannotReturn.class/README.md A Kernel.package/BlockCannotReturn.class/class/signalling/result_from_.st M Kernel.package/BlockCannotReturn.class/definition.st M Kernel.package/BlockCannotReturn.class/instance/accessing/deadHome.st M Kernel.package/BlockCannotReturn.class/instance/accessing/deadHome_.st A Kernel.package/BlockCannotReturn.class/instance/accessing/home.st A Kernel.package/BlockCannotReturn.class/instance/accessing/home_.st R Kernel.package/BlockCannotReturn.class/instance/accessing/result.st R Kernel.package/BlockCannotReturn.class/instance/accessing/result_.st R Kernel.package/BlockCannotReturn.class/instance/exceptiondescription/defaultAction.st R Kernel.package/BlockCannotReturn.class/instance/exceptiondescription/isResumable.st A Kernel.package/CannotReturn.class/README.md A Kernel.package/CannotReturn.class/definition.st A Kernel.package/CannotReturn.class/instance/accessing/result.st A Kernel.package/CannotReturn.class/instance/accessing/result_.st A Kernel.package/CannotReturn.class/instance/testing/isResumable.st M Kernel.package/Context.class/instance/private-exceptions/cannotReturn_.st M Kernel.package/Context.class/instance/private/cannotReturn_to_.st A Kernel.package/ContextCannotReturn.class/README.md A Kernel.package/ContextCannotReturn.class/class/signalling/result_to_.st A Kernel.package/ContextCannotReturn.class/definition.st A Kernel.package/ContextCannotReturn.class/instance/accessing/target.st A Kernel.package/ContextCannotReturn.class/instance/accessing/target_.st R Komitter.package/Komitter.class/instance/announcement/classModified_.st R Komitter.package/Komitter.class/instance/announcement/classMoved_.st R Komitter.package/Komitter.class/instance/announcement/classRemoved_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60044.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60045.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60044.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60045.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60045 18303 Kommiter contains 3 method sending #halt https://pharo.fogbugz.com/f/cases/18303 18163 Context cannotReturn users should split return from context and blockClosure https://pharo.fogbugz.com/f/cases/18163 http://files.pharo.org/image/60/60045.zip

May 30, 2016

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

by Nicolai Hess

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

May 30, 2016

[pharo-project/pharo-core]

by GitHub

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

May 30, 2016