February 2016 - Pharo-users

Writing a dictionary as XML?
by phil＠highoctane.be Feb. 18, 2016

Feb. 18, 2016

How can I write a dictionary (OrderPreservingDictionary) as an XML string? XMLWriter is more like a step by step thing. TIA Phil

2 1

[ANN] OSUnix and OSLinuxUbuntu on new UFFI
by Torsten Bergmann Feb. 18, 2016

Feb. 18, 2016

These two projects (who were based on NativeBoost in Pharo 4) are now updated to new UFFI in Pharo 5 which means they are loadable in recent Pharo 5 image and all tests pass. So if you are working on Linux/Unix you might wan to check them out in latest Pharo 5 by loading them from Catalog browser. A BIG THANKS to Esteban for helping me in the conversion and updating the new Unified FFI (UFFI) according to the issues that were found during the conversion. More is in the pipe ... step by step it goes! Bye T.

4 3

rollToArity: ?
by Alexandre Bergel Feb. 18, 2016

Feb. 18, 2016

Esteban, What Object>>rollToArity: is supposed to do? It belongs to UnifiedFFI Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 1

Fwd: [squeak-dev] New Cog VMs available as per VMMaker.oscog-eem.1679/r3602
by John Pfersich Feb. 18, 2016

Feb. 18, 2016

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 >

2 1

cleaning up Pharo images
by Peter UhnÃ¡k Feb. 18, 2016

Feb. 18, 2016

Hi, is there a way to minimize/clean up Pharo image/changes files after an application has been installed into it? Currently I have the base image sitting at 65MB and changes at 36MB, which is massive considering only source code was added. I've tried running 'Smalltalk cleanUp: true', which I cannot run from command line because it asks a questionâ¦ can this be circumvented? Running it manually however has driven the image size down to 46MB, not changing the .changes file however. Are there other ways to make the image smaller? Do I need such massive changes file? Can't I just empty it completely? Thanks, Peter

2 1

[ANN] OSUnix and OSLinuxUbuntu on new UFFI
by Torsten Bergmann Feb. 18, 2016

Feb. 18, 2016

Sebastian wrote: >I just know that Windows users should not replace their current images with the latest >images yet. Otherwise they might have trouble. One always might have trouble when one uses the latest beta image and CI built VM. No need to warn about this. Nonetheless: ============ Using #50586 image with the "living on the edge" Spur VM (http://files.pharo.org/vm/pharo-spur32/win/PharoVM-Spur32-win-latest.zip last built 17.02.2016 18:53) there is a reproducable case when one opens the browser and selects a method in a class browser and then another method of the same class. This crashes the VM. Using the latest "stable" Spur VM it will work: http://files.pharo.org/vm/pharo-spur32/win/stable-20160203.zip Use that VM version until issue #17541 is solved. Keep on reporting - but please next time stay away from hijacking non-related threads and give more details: In the world menu there is "System" -> "System Reporter". In this reporter the "Image" as well as the "VM General" is already selected. With this you can find out and report exactly the VM/image combination that you used. You should provide this in future bug reports. For other "Non-Pharo VM crashing" bugs it is enough to report just the image version (which can be easily seen also in World menu "System" -> "About". Also it makes more sense to report such findings to the developer list (who usually work on latest and greatest). Bye Torsten (without h)

1 0

[ANN] Pharo Sprint 26 Feb
by Marcus Denker Feb. 18, 2016

Feb. 18, 2016

We will organize a Pharo sprint / Moose dojo Friday, 26 Feb, starting at 10:00am. (Local Time Lille). It will be at the Inria Lille, Building B, third floor (RMoD offices). Remotely, you can join us on Slack or the IRC channel #pharo on irc.freenode.net <http://irc.freenode.net/> server. During the sprint, we will try to synchronize local and remote Pharo sprinters. As the building is not open to the public, please contact us before if you plan to come.

1 0

[ANN] OSUnix and OSLinuxUbuntu on new UFFI
by Torsten Bergmann Feb. 18, 2016

Feb. 18, 2016

Sebastian wrote: >I don't want to spoil the great news, but actually the most recent >changes break Pharo 5.0 with SpurVM on Windows 8. >... > >I tried several older snapshots of the VM and the Pharo images listed in >the PharoLauncher but none work. Seriously you should rethink your way of COMMUNICATION: 1. This thread here is about a specific UNIX package and you tell us about a general Pharo problem you seem to have on a completely different platform: WINDOWS. => ???? 2. You "hijack" this thread instead of opening a separate one specific to the problem and asking if others might have the same issue. => ???? 3. You "give a general warning" to others already to "keep their images"? No details on what modification could possibly harm the image. => ???? 4. You talk about a broken Pharo 5 - but do not tell us what/where it is broken. Did the image not come up, is there a problem in a tool or when calling something/using UFFI. => ???? 5. You talk about "recent changes" without telling us when it started or at a minimum with which image version you face the problem. When it worked before then one can easily use Launcher to incrementally download and check several images to find out which change broke something. => ???? 6. You say you cant build a new image since a few days without giving any information what packages you load or how you build your custom images. => ???? 7. You said that you used several combination of VM and images but do not tell us which one you used/expected to work. => ???? Sorry - do you really think this is a good way to report a problem? How do you expect someone to invest his sparse spare time to help you? Maybe it is much easier to "just lament" instead of "being supportive". As an info: I also use Pharo 5 (even latest images up to Pharo 5 #50586) on Windows with Spur since 2 months. Found smaller issues that I reported, most of them are already adressed because I was able to give a clear picture of what the problem was. And yes - times are a little bit shaky because of Spur and UFFI - but this was already announced/warned before and situation has improved a lot with latest updates. Please do us all a favour and open a new thread or much better a bug report with exact details to reproduce if you have any finding. Before that check your setup: for SpurVM you should try: http://files.pharo.org/vm/pharo-spur32/win/stable-20151214.zip (which is the Spur build from December) http://files.pharo.org/vm/pharo-spur32/win/PharoVM-Spur32-win-latest.zip (which is the latest CI built) with the highest image build number: http://files.pharo.org/image/50/ For non-spur images (Pharo 4.0 and Pharo 5.0 up 50496 update) you need the old non-spur VM: http://files.pharo.org/vm/pharo/win/ If you use Launcher check that you use the latest green build from https://ci.inria.fr/pharo/view/Launcher and that spur and non-spur Vm is correctly configured in the Pharo launcher settings. Thanks Torsten

2 1

Getting error reason on command line
by Peter UhnÃ¡k Feb. 17, 2016

Feb. 17, 2016

Hi, is it possible to get error description on stdout similarly to warning? â Currently only the return value is changed but no output is produced. Thanks, Peter

1 0

gtoolkit 3.10 overview
by Tudor Girba Feb. 17, 2016

Feb. 17, 2016

Hi, I promised to send a summary of the larger changes that came with the recent integration of GToolkit 3.10. Here it is: http://www.humane-assessment.com/blog/gtoolkit-3-10/ Please let us know what you think. Cheers, Doru -- www.tudorgirba.com www.feenk.com "What is more important: To be happy, or to make happy?"

3 3