- Pharo-users - lists.pharo.org

Compiling Pharo to C++

by kilon.alios

So doing further research into Unreal , I have reached the conclusion that the best way to integrate Pharo is make a compiler that takes Pharo code and compiles it to C++. I have barely scratch such area when I was playing around with Pharo AST nodes. Any advice / ideas how to accomplish this ? Currently my goal is to start super simple, with compiling small pharo code fragments to C++ code and then much later on even introduce extensions to the pharo language to accommodate for C++ features like templates , pointers (FFI probably already cover this) , static types etc. Obviously if I can keep the pharo syntax intact would be the ideal option. -- View this message in context: http://forum.world.st/Compiling-Pharo-to-C-tp4877775.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Feb. 16, 2016

Re: [Pharo-users] Bloc Space within a Space

by Alain Plantec

> > But how to drive it? e.g. simulate events ok, so we agree here. Bloc is done in that perspective. For now, you have to implement your own BlocSpace with an adequate #processEvents method, your can also implement your own main loop manager (polymorphic with BlMainLoopManager). > > > Pharo Smalltalk Users mailing list wrote >> but your code does not make sense regarding how Bloc is designed >> you can have one and only one **active** BlocSpace at a time. > > I understand from a Pharo perspective that one is only expected to have one > *real* space at a time which is receiving hardware events and such, but what > prevents us from simulating Spaces?! If there is a SpaceElement, and > Elements can be placed in the World, the principle of uniformity encourages > that a SpaceElement can be placed there like any other. yes, your right. I had that idea in mind. The only problem we have today is that the current implementation of damages repairing makes the assumption that a SpaceElement is at 0@0. (need to review BlSimpleRedrawer for that). > > > Pharo Smalltalk Users mailing list wrote >> imagine that a BlocSpace is a Pharo image. >> Making your code working would mean that we would be >> able to run a Pharo image within a Pharo image. > > Exactly, like the VM simulator! Sign me up! This was the level of uniformity > and explorability that I always wished in Morphic. :) ok, so not infeasible but we are not there today. Do not forget that Bloc is currently implemented by a very small team. lets do it step by step. Cheers Alain > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Bloc-Space-within-a-Space-tp4877474p4877733.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Feb. 16, 2016

Re: [Pharo-users] Metacello reverse project dependency

by Peter UhnÃ¡k

Unfortunately #includes: doesn't seem to matter and I still get errors. I tried to somehow summarize my findings with minimal code & results here http://peteruhnak.com/metacello/ On Mon, Feb 15, 2016 at 11:31 PM, Werner Kassens <wkassens(a)libello.com> wrote: > Hi Peter, > have you looked at metacellos #includes: method? > from https://code.google.com/archive/p/metacello/wikis/APIReference.wiki : > "When 'Example-AddOn' is loaded, load 'Example-UI'" > includes: #('Example-UI' ); > werner > > On 02/13/2016 11:26 PM, Peter UhnÃ¡k wrote: > >> Hi, >> >> I have the following situation: >> >> I have ProjectMain, and ProjectPlugin, now normally the Plugin depends >> on Main, however I would like to load Plugin as part of Main. >> >> The problem is that I can't specify to load Plugin after Main has been >> already fully loaded, if I do something like this >> >> BaselineOfMain>>baseline: spec >> <baseline> >> spec >> for: #common >> do: >> [ spec >> baseline: 'Plugin' >> with: [ spec >> repository: '...'; >> loads: #('default' OR 'plugin') ]. >> spec >> package: 'Main' with: [ spec requires: #(more stuff) ]; >> spec group: 'default' with: #('Main'). >> specgroup: 'complete' with: #('default' 'Plugin') ] >> >> The BaselineOfPlugin has two groupsâ¦ "default", which loads also "Main", >> and "plugin", which doesn't. >> >> Now the problem is that there is no guaranteed way that Plugin will load >> after Main (in fact the should happen). If I load the plugin's #default, >> then Metacello ends up in an endless loop for some reason, and if I load >> #plugin, then it will load it before the Main which will break it >> (because Plugin has dependencies on main). >> >> So my question is: >> is it possible to reverse it somehow? >> Maybe add at the end `specpostLoadDoIt: #postLoadPlugins`, and then in >> that method manually load the plugins with Metacello/Gofer? Or is there >> a better way? >> >> Thanks, >> Peter >> > >

Feb. 16, 2016

Fwd: [squeak-dev] New Cog VMs available as per VMMaker.oscog-eem.1679/r3602

by John Pfersich

FYI. I noticed that Eliot didn't send to Pharo-users. Sent from my iPad Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: February 15, 2016 at 11:39:29 PST > To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > Cc: "newspeaklanguage(a)googlegroups.com" <newspeaklanguage(a)googlegroups.com>, Discusses Development of Pharo <pharo-dev(a)lists.pharo.org>, The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Subject: [squeak-dev] New Cog VMs available as per VMMaker.oscog-eem.1679/r3602 > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > Hi All, > > first of all, apologies for the long wait for new VMs. I know there are bugs that these VMs address and that it's been 5 months since VMs were last made is something I regret. The wait was due to my developing the 64-bit Spur Cog JIT VM which required surgery not just to the Cogit but also to Slang. I beg your forgiveness. > > Secondly, the Mac VMs are much changed, using John McIntosh's Cocoa support libraries. The old Carbon UI VMs are history. That means that Cog supports building on contemporary Mac OS releases. These VMs were built on 10.9; I like the 3D look much more than the 10.10 one ;-). The VMs are also signed, so installing them should be easier. > > Thirdly, these VMs include 64-bit JIT support. There is an updated squeak trunk image at http://www.mirandabanda.org/files/Cog/SpurImages for you to try. As yet the 64-bit Vms do not include an FFI plugin. I hope to rectify this soon. > > Finally I have included Pharo Mac VMs, not to displace the official Pharo VMs, but to test my build process. I hope that in very few months the svn repository will be moed to githup and that Esteban and I will build official VMs from the same repository. > > > > The VMs are here: http://www.mirandabanda.org/files/Cog/VM/VM.r3602 > > CogVM binaries as per VMMaker.oscog-eem.1679/r3602 > > Include 64-bit Spur VMs for Mac OS X x64 and Linux x64. N.B. As yet these VMs > lack FFI support. > > Move all Mac OS X VMs to the Cocoa libraries. Minimum supported version should > be 10.6.x. The Mac OS X VMs are signed and so should install properly without > having to disable the launch security checks. > > > Bug Fixes and Improvements: > > General: > Add vmParameter 20 to answer the utc microseconds at startup. > > > CoInterpreter: > Remove the atCache from the CoInterpreter. It's of little benefit given the > Cogit. > > ceSend: et al need to add looked up methods to the method cache, otherwise > methods only found through machine code sends will not be jitted. > > Fix slip in maybeSelectorOfMethod: which will improve back traces > including methods containing pragmas (including primitives). > > Modify secret primtiive 161, primitiveSetIdentityHash so that with 0 args it > answers whether an object has an identity hash. This is vacuously true for V3, > but is meaningful in Spur. > > > Cogit: > Fix /horrible/ bug with primitive error codes and fixups. The adjustment of the > initialPC to skip the primitive and error code, if any, was done after > generating fixups for backward branches, and hence these branches were bogus. > Object>>shallowCopy in Spur is subject to this, but amazingly enough it has not > surfaced before now. Fix this by adjusting the initialPC before scanMethod > scans for fixups. > > Fix bug in Spur machine-code at:put: on 32-bit bits objects; method failed to > fail for negative values. > > Fill unused portions of methods with the stop instruction, not nop. > > Explicitly initialize the code zone with stops. Explicitly clear the > reclaimed portion of the method zone after a compaction. > > Include the reclaimed portion of the method zone in the I-cache flush > after a compaction: no point in leaving it in cache since it isn't a > valid call/jump target. > > > Spur: > Maintain the survivor count on scavenge. > > Fix start up of images containing >= 16 segments. The old code assumed > numSegments < 16 and failed to grow the segment records, resulting in objects > in segments greater than 15 to not be swizzled, and a resulting crash. > > Spur Cogit: Support CompiledMethod indexing in genPrimitiveAt[Put]. Hence fix > the regression in at:[put:] whereby in Spur one could access the literals part > of a method as bytes. > Add a machine-code primitive for objectAt: to provide fast literal and header > access on Spur. > > Add 16-bit indexability to Spur. Generate slimmer code for > positive32BitValueOf: on 64-bit Spur. > > Fix a bug with out-of-place two-way become, which got the hash copy the wrong > way round. By default, the hash stays with the reference in two-way become. > > Fix what appears to be a compiler bug with in-place two-way-become by treating > the headers to be swapped so that remembered flags are swapped and hash bits > are swapped if required. This fixes a bug with in-place two-way become of > objects that are the same size on the heap. One object's contents would not > be updated correctly. > > Implement ephemeron queue primitive. Add an image flag that controls the > finalization support (StackInterpreter instVar newFinalization). If unset, > finalization is as currently expected; WeakArray finalizes all WeakArrays in > its registries on each finalization (which does not scale!). If set, then both > fired ephemerons and bereaved weak arrays are added to the finalization queue > and the finalization semaphore is signalled. In this regime the image is > expected to send mourn to each element of the queue, and weak arrays will send > themselves finalize in mourn, side-stepping the finalizeValues steps and > rendering WeakArray's FinalizationDependents and WeakRegistry obsolete. > The bit is set via > Smalltalk vmParameterAt: 48 > put: ((Smalltalk vmParameterAt: 48) bitOr: 64). > > > Slang: > Fix bad regression in type inference from VMMaker.oscog-eem.1587. > returnTypeForSend:in: can only default return types to sqInt for unknown > selectors. The rewrite in VMMaker.oscog-eem.1587 inadvertently defaulted the > return type of known methods whose return type was yet to be determined to > sqInt. The fix is to only default to sqInt if there is no known method for the > given selector. This fixes, for instance, the weird flipping of the type of > 32-bit Spur's headerWhileForwardingOf:,which should always be #sqLong. > > Fix bad bug in type inferrence. Avoid computing variable and return types > prematurely i.e. don't derive types from as-yet-untyped methods. > > Fix baaaad bug in node:typeCompatibleWith:inliningInto:in: which was looking > up the type of the formal parameter in inlining in the target method, not the > method being inlined! > > > Newspeak: > Fix bug in MNU for cogged dynamic super sends - should start looking for > #doesNotUnderstand: in the superclass not the receiver class. Unify MNU > lookup between absent and present receiver sends as a result. > > Further fix outer send MNU by not confusing lkupClass and lkupClassTag. > Push setting lkupClassTag down to clarify it is for new cache entries. > > > Plugins: > Fix the FilePlugin's unnecessary fullGC on Spur. > Include the file sync prim in the FilePrims plugin. > > ThreadedFFIPlugin: > - ExternalAddress now are taken correctly (nor as ByteArray or Alien, because > they are different beasts). > - allow pushing of pointers to any type (into a ByteArray, an ExternalAddress > or an Alien), to allow passing parameters style int*, float*, etc. > - allow reading in memory to allow read chunks of ByteArray > > Added ThreadedFFIPlugin>>#primitiveLoadSymbolFromModule (copy and adapt from > IA32ABIPlugin). > > Fix coercion problems on FFI plugin (IA32 & ARM) > - character were not correctly mapped back > - floats were not being well checked > - external addressed needs to be treated as aliens for the purpose of coercing > them as pointers (bad regression by Eliot) > > Alien Plugins: > Fix missing primitive failure for Alien typeAt: 0 [put:]. > Add word accessors to Alien. > > _,,,^..^,,,_ > best, Eliot >

Feb. 16, 2016

Re: [Pharo-users] Bloc Space within a Space

by Sean P. DeNigris

Pharo Smalltalk Users mailing list wrote > looking at your codeâ¦now I think that Alex answer was the right one :) Hopefully I can convince you otherwise ;) Pharo Smalltalk Users mailing list wrote > in fact one should be able to open a world in a world. That was always a wish of mine in Morphic, however in Bloc, the equivalent is a space, not a Bloc world. A Bloc world only holds the objects on the desktop, not the halos or hand. Pharo Smalltalk Users mailing list wrote > one should be able to script a space, > thus, one should be able to write a test with a local BlocSpace, adding > elements into it and so on But how to drive it? e.g. simulate events Pharo Smalltalk Users mailing list wrote > but your code does not make sense regarding how Bloc is designed > you can have one and only one **active** BlocSpace at a time. I understand from a Pharo perspective that one is only expected to have one *real* space at a time which is receiving hardware events and such, but what prevents us from simulating Spaces?! If there is a SpaceElement, and Elements can be placed in the World, the principle of uniformity encourages that a SpaceElement can be placed there like any other. Pharo Smalltalk Users mailing list wrote > imagine that a BlocSpace is a Pharo image. > Making your code working would mean that we would be > able to run a Pharo image within a Pharo image. Exactly, like the VM simulator! Sign me up! This was the level of uniformity and explorability that I always wished in Morphic ----- Cheers, Sean -- View this message in context: http://forum.world.st/Bloc-Space-within-a-Space-tp4877474p4877733.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Feb. 16, 2016

Re: [Pharo-users] Bloc Space within a Space

by Sean P. DeNigris

Pharo Smalltalk Users mailing list wrote > please do not ask too much... I can't help it! Pharo has spoiled me ha ha Pharo Smalltalk Users mailing list wrote > Reaching this state requires a huge amount of work but we are almost there > :) Thank you for all that work. It is exciting to hear that we are close to launch!! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Bloc-Space-within-a-Space-tp4877474p4877732.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Feb. 16, 2016

Re: [Pharo-users] Monticello reverse project dependency

by Werner Kassens

Hi Peter, have you looked at metacellos #includes: method? from https://code.google.com/archive/p/metacello/wikis/APIReference.wiki : "When 'Example-AddOn' is loaded, load 'Example-UI'" includes: #('Example-UI' ); werner On 02/13/2016 11:26 PM, Peter UhnÃ¡k wrote: > Hi, > > I have the following situation: > > I have ProjectMain, and ProjectPlugin, now normally the Plugin depends > on Main, however I would like to load Plugin as part of Main. > > The problem is that I can't specify to load Plugin after Main has been > already fully loaded, if I do something like this > > BaselineOfMain>>baseline: spec > <baseline> > spec > for: #common > do: > [ spec > baseline: 'Plugin' > with: [ spec > repository: '...'; > loads: #('default' OR 'plugin') ]. > spec > package: 'Main' with: [ spec requires: #(more stuff) ]; > spec group: 'default' with: #('Main'). > specgroup: 'complete' with: #('default' 'Plugin') ] > > The BaselineOfPlugin has two groupsâ¦ "default", which loads also "Main", > and "plugin", which doesn't. > > Now the problem is that there is no guaranteed way that Plugin will load > after Main (in fact the should happen). If I load the plugin's #default, > then Metacello ends up in an endless loop for some reason, and if I load > #plugin, then it will load it before the Main which will break it > (because Plugin has dependencies on main). > > So my question is: > is it possible to reverse it somehow? > Maybe add at the end `specpostLoadDoIt: #postLoadPlugins`, and then in > that method manually load the plugins with Metacello/Gofer? Or is there > a better way? > > Thanks, > Peter

Feb. 15, 2016

Re: [Pharo-users] Bloc Space within a Space

by Alain Plantec

Hello again Sean, looking at your codeâ¦now I think that Alex answer was the right one :) in fact one should be able to open a world in a world. one should be able to script a space, thus, one should be able to write a test with a local BlocSpace, adding elements into it and so on but your code does not make sense regarding how Bloc is designed you can have one and only one **active** BlocSpace at a time. imagine that a BlocSpace is a Pharo image. Making your code working would mean that we would be able to run a Pharo image within a Pharo image. > > s := BlBlocSpace new. ok > root := s rootElement. ok > root extent: 500 @ 500. ok > root > openInWorld; > yourself. this does not make sense for me > rect := BlElement exampleRectangle. > rect openInWorld: root world. this can make sense > s redraw. > root updateDrawing. this canot work also because only the current space can draw. ok, at least it means that we have to write good documentation about the bloc design. Cheers Alain > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Bloc-Space-within-a-Space-tp4877474.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Feb. 15, 2016

Re: [Pharo-users] Bloc Space within a Space

by Alain Plantec

Hello Sean, Thanks for your remarks. I think that the current space design has the adequate abstractions to do the kind of tests you want. And youâre right, it should be possible. But please do not ask too much. Before having this kind of TDD possible we have to reach a point where we can use Bloc and Brick with real user input events. Maybe we are wrong but this was our approach. Reaching this state requires a huge amount of work but we are almost there :) Cheers Alain > Le 14 fÃ©vr. 2016 Ã 19:26, Sean P. DeNigris <sean(a)clipperadams.com> a Ã©crit : > > Aliaksei Syrel wrote >> Space is not something you want to embed in another space. > > That's where you're wrong ;-) That's exactly what I want to do! > > > Aliaksei Syrel wrote >> Space manages UI thread, event fetching, alarms and many other low level >> stuff > > Yes! That's all the stuff I want to stub out and control. Imagine I want to > control time in my space e.g. run a simulation at 10x speed... > > > Aliaksei Syrel wrote >> Universe contains spaces and there can be only one running space at a time >> - read >> there can be only one active UI thread and event fetcher in the system. > > Yes, this is what I am disappointed before. Of course that makes sense in > practice in the normal operation of the system, but limits one's creativity > to pre-approved uses. IMHO this is the kind of coding-for-one-world-view > that made Morphic infuriating to really try to reinvent. > > > Aliaksei Syrel wrote >> You can create a separate 'Bloc-Test' space and do testing there. > > I should have been more specific. Yes, one can do functional testing, but > one can not stub out the dependencies and unit test properly. In fact, IMHO > this area of the design is a symptom of lack of TDD. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Bloc-Space-within-a-Space-tp4877474p4877492.html > Sent from the Pharo Smalltalk Users mailing list arch

Feb. 15, 2016

Re: [Pharo-users] Problem with gitfiletree in pharo 5

by Norbert Hartl

Thanks that works! Norbert > Am 15.02.2016 um 11:17 schrieb Thierry Goubier <thierry.goubier(a)gmail.com>: > > Hi Norbert, > > yes, there is an issue with the OSProcess plugin on Mac which isn't solved yet. In the meantime, Mariano's OSSubprocess works and a version of GitFileTree with it is available this way: > > Metacello new > baseline: 'FileTree'; > repository: 'github://dalehenrich/filetree:issue_171/repository'; > load: 'Git' > > [1] http://forum.world.st/ANN-OSSubprocess-first-milestone-tp4871382p4871459.ht… > > Thierry > > Le 15/02/2016 10:56, Norbert Hartl a Ã©crit : >> Today I tried to use a pharo 5 image for my project. I installed gitfiletree but could not access my existing git repo I use with pharo 4. >> In >> >> MCFileTreeGitRepository>>#gitBranchs >> >> the output for the git command is an empty string while executing the same on the console gives me >> >> * master >> >> Is this a OSProcess problem? Where to look at to find the culprit? >> >> thanks, >> >> Norbert >> >> >> > >

Feb. 15, 2016