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

Re: [Pharo-dev] OS-Windows and UnifiedFFI
by Nicolai Hess June 25, 2016

June 25, 2016

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

3 15

Reordering working directory mess
by Esteban Lorenzano June 24, 2016

June 24, 2016

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

14 21

debuggerCompleteToSender (was Re: Having comments for pragma?)
by Ben Coman June 24, 2016

June 24, 2016

On Fri, Jun 24, 2016 at 9:54 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > A pragma may be very obscure. For example, I do: > Pragma allInstances anyOne > => <debuggerCompleteToSender> > > If I want to know more about this <debuggerCompleteToSender> is actually > quite challenging. > I see many methods having that pragma, but not idea what it is for. > I see that Halt>>signalerContext and Process>>complete: that use that > pragma somehow. But still, I have no idea when I should use that pragma in > my method. > > Sorry I don't know enough of Pragma architecture to form an opinion on your question, but I can give you some background on debuggerCompleteToSender. There are two cases where the debugger interacts with a halt statement. The first is when a halt is first encountered in running code. This could be "Halt now" or "self halt" which respectively invoke... Halt>>now self signal. Object>>halt Halt now. Now you don't want the debugger to open in those methods, but the method that sent the message. The problem with the implementation prior to <debuggerCompleteToSender> was that while it was okay for signalerContext to be search the context chain for a Halt object so the debugger could open in the sender of #now, that meant the debugger would open inside "self halt" since it sends #now. So there was an #or: to look for #halt being sent, and an #or: for #haltOnce beign sent, and the dozen other senders of Halt>>now were ignored, or otherwise you'd need a dozen #or: conditions. The second case is when you are stepping through code you come across another "self haltOnce" and previously when you <Step Over> the debugger would end up several methods "in" and it would take eight or so <Steps> to get back out to the method containing the "self halt". (and this really annoyed me enough to fix it). So DebuggSession>>stepOver: calls Process>>completeStep: which calls Process>>complete: Again (vaguely I remember) it originally only searched up the context chain for senders of #halt and the dozen others halt methods were ignored and so they failed to set the debugger to the correct location. >From from #complete: the call "self completeTo: aContext sender" moves up the context chain, and completeTo: recurses back to complete. This recursion only happens while the error class is Halt and while the context methods have the pragma, otherwise it falls through to return suspendedContext as it unwinds. So having written all that to remind myself, the short answer of the net effect is that a first method with <debuggerCompleteToSender> can call another method with <debuggerCompleteToSender> which can call another <debuggerCompleteToSender> methods etc to any depth, until eventually Halt>>now is called to signal the exception, then all calls get unwound up to the first method with <debuggerCompleteToSender>, and the debugger lands in its sender. I was not completely happy with the pragma's name, but I was really at a loss what to name it, and so... since I was fixing the debugger, and was all happening in the "completion" machinery, and it unwound to the sender... *shrugs* Now, where to add all that as a comment? HTH, cheers -ben

1 0

Impossible to delete a class
by Valentin Ryckewaert June 24, 2016

June 24, 2016

Hello everyone, I just downloaded the last Pharo version and I found a bug when I tried to delete a class. The last version deprecated a method "name" and it looks like SmalltalkImage>>errorReportOn: doesn't like this. When you try to delete a class there is an infinite loop everytime. Valentin

2 1

catalog will be down 1hr
by Esteban Lorenzano June 24, 2016

June 24, 2016

Hi, I will apply some updates to catalog (backend, they will not be visible) cheers, Esteban

4 4

[pharo-project/pharo-core] b637cf: 60112
by GitHub June 24, 2016

June 24, 2016

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: b637cf9547873482910a1cf6159b60d220b6e0c9 https://github.com/pharo-project/pharo-core/commit/b637cf9547873482910a1cf6… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-24 (Fri, 24 Jun 2016) Changed paths: A ConfigurationOfTxText.package/ConfigurationOfTxText.class/instance/versions/version2125_.st M Kernel.package/Halt.class/class/halting/once.st M Ring-Core-Kernel.package/RGElementDefinition.class/instance/accessing/package.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60111.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60112.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60111.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60112.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M TxText-Athens.package/TxAdapterBindings.class/instance/initialize/initializeBindings.st R TxText-Model.package/TxModel.class/instance/copying/postCopy.st Log Message: ----------- 60112 18597 fix haltOnce to open debugger in the right place https://pharo.fogbugz.com/f/cases/18597 18539 Can not browse methods for a change set that modified class comments https://pharo.fogbugz.com/f/cases/18539 18073 TxModel >>#postCopy sends #halt https://pharo.fogbugz.com/f/cases/18073 http://files.pharo.org/image/60/60112.zip

1 0

[pharo-project/pharo-core]
by GitHub June 24, 2016

June 24, 2016

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

1 0

[pharo-project/pharo-core] b67123: 60111
by GitHub June 24, 2016

June 24, 2016

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

1 0

[pharo-project/pharo-core]
by GitHub June 24, 2016

June 24, 2016

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

1 0

[pharo-project/pharo-core] d93829: 60110
by GitHub June 24, 2016

June 24, 2016

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

1 0