- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo 5] Symbol #'distance_2pts' not accepted at package installation

by Max Leske

Hilaire, did you see the comments in the issue you opened? Cheers, Max > On 24 Apr 2016, at 12:10, Hilaire <hilaire(a)drgeo.eu> wrote: > > Hi Nicolai, > > http://smalltalkhub.com/#!/~HilaireFernandes/DrGeo > > You can't use the installation procedure described in the wiki, because > Pharo5 also got stuck when loading a dependent package (gettext package > to name it). > You should manually load the DrGeoII-Core package, then DrGeoII-Polymoprh > > The problem occurs when loading DrGeoII-Core. > > Hilaire > > > > Le 24/04/2016 11:41, Nicolai Hess a Ã©crit : >> >> Hi Hilaire, >> >> can you point me to the repository where this DrGeo package is. >> >> > > -- > Dr. Geo > http://drgeo.eu > >

April 24, 2016

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

by Nicolai Hess

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

April 24, 2016

Re: [Pharo-dev] [Pharo 5] Symbol #'distance_2pts' not accepted at package installation

by Hilaire

Hi Nicolai, http://smalltalkhub.com/#!/~HilaireFernandes/DrGeo You can't use the installation procedure described in the wiki, because Pharo5 also got stuck when loading a dependent package (gettext package to name it). You should manually load the DrGeoII-Core package, then DrGeoII-Polymoprh The problem occurs when loading DrGeoII-Core. Hilaire Le 24/04/2016 11:41, Nicolai Hess a Ã©crit : > > Hi Hilaire, > > can you point me to the repository where this DrGeo package is. > > -- Dr. Geo http://drgeo.eu

April 24, 2016

Re: [Pharo-dev] [Pharo 5] Symbol #'distance_2pts' not accepted at package installation

by Nicolai Hess

2016-04-24 11:34 GMT+02:00 Hilaire <hilaire(a)drgeo.eu>: > This symbol is not accepted when installing DrGeo package in Pharo 5, > but in the playground it is ok to type in symbol #'distance_2pts' > > > https://pharo.fogbugz.com/f/cases/18071/Symbol-distance_2pts-not-accepted-a… > > Hilaire > > Hi Hilaire, can you point me to the repository where this DrGeo package is. > > -- > Dr. Geo > http://drgeo.eu > > >

April 24, 2016

[Pharo 5] Symbol #'distance_2pts' not accepted at package installation

by Hilaire

This symbol is not accepted when installing DrGeo package in Pharo 5, but in the playground it is ok to type in symbol #'distance_2pts' https://pharo.fogbugz.com/f/cases/18071/Symbol-distance_2pts-not-accepted-a… Hilaire -- Dr. Geo http://drgeo.eu

April 24, 2016

Re: [Pharo-dev] Why does not have a standard Tree Structure in Pharo? ( stepharo )

by Pierce Ng

On Sat, Apr 23, 2016 at 12:03:03PM +0200, phil(a)highoctane.be wrote: > There are BTrees (I made a copy in my Smalltalkhub): > http://www.smalltalkhub.com/#!/~philippeback/Trees > http://stackoverflow.com/questions/6917310/tree-implementations-in-smalltalk Also http://smalltalkhub.com/#!/~hernan/Trees, a port of Bruce Samuelson's generalized tree implementation from the early 90s. Pierce

April 24, 2016

New Cog VMs available

by Eliot Miranda

... at http://www.mirandabanda.org/files/Cog/VM/VM.r3684 CogVM binaries as per VMMaker.oscog-eem.1834/r3684 General: Correct undue sign extension wile promoting 32 to 64 bits int in fetchLong64:ofObject: This was causing trouble in non spur object memory (V3). Fix slowdown of update on 64-bit x64 by using int variables for the tides in sqExternalSemaphores.c and inline assembler for the sqCompareAndSwap in sqAtomicOps.h. Fix slips in offset time primitives. They need to pop argumentCount + 1, not argumentCount. Define an optional primitive as the fast primitive fail code so that unselected optional primitives are in the prmitiveTable as fast primitive fails. Spur: Have WideString>>at: fail to answer an out-of-range character in the interpreter primitive (as well as in the JIT). Fix bug in following state on primitive failure. The old code would always follow to depth 1, even if the accessor depth was 0. Hard-code primitiveSize's depth to 0 (accessing length in at:[put:] and size causes the stack depth computation to answer 1 instead of 0 for these primitives. Fix assert and dequeueMourner for case where mournQueue is nil. - fixed a bug in receiver accessing in immutability primitive for mirror primitive. - change primitiveSetOrHasIdentityHash to patch the class table if the new hash is set to a behavior (the primitive knows it's a behavior if the second (optional) argument is true) For example: FullBlockClosure tryPrimitive: 161 withArgs: {38.true} No longer follow the method and context fields in a closure in activateNewClosureMethod:numArgs:mayContextSwitch:; the caller will have failed if these are forwarders, so no need to check again. Cogit: Add a primitive that answers pc map data for methods which can be used to better decorate methods in the VM Profiler. Refactor the pc map enumeration facilities so that the Sista pic data primitive can share the same enumerator. Do this by collapsing the isBackwardBranch and annotation parameters into a single parameter. Follow selectors in the openPICList post Spur become. Fix the ARM's caller-saved register mask now that we can name all the actual registers. Reworked machine code generation of immutability so for common stores it uses a single trampoline for both store checks and immutability checks. - improved support for register allocation: branch merge successfully compiled with register moved instead of spilling. Sista Cogit: Don't bother to add counters to conditional jumps implementing and: and or:. Added the remote inst var access bytecode in sista V1 bytecode set without interfering with existing code. Plugins: Upgrade LargeIntegersPlugin to v2.0 LargeInteger primitives now deal with 32-bits digits. No change to image code. Memory is 8 bytes aligned on Spur. When storing 32/64 bits large integers values, allways fill the eight bytes whatever the effectivily used size, rather than bother with dissertion of size. Generate integer type checking as C macros rather than direct/indirect interpreterProxy function call in plugins. This, and 32-bit accessing mean singificantly faster large integer arithmetic. Fix primAlienReplace to use positiveMachineIntegerValueOf: instead of positive32BitValueOf:. BitBltPlugin operates on 32bit word units, therefore it's better to declare its operands as 'unsigned int' rather than sqInt. On 32bit VM, this doesn't change anything, but on 64bits spur, it makes this snippet work: | wideString source pos blt expectedWideString | source := #[1 64 255 14 1 64 48 251]. expectedWideString := WideString fromByteArray: source. wideString := WideString new: source size // 4. pos := 0. blt := (BitBlt toForm: (Form new hackBits: wideString)) sourceForm: (Form new hackBits: source). blt combinationRule: Form over; sourceX: 0; sourceY: pos // 4; height: wideString byteSize // 4; width: 4; destX: 0; destY: 0; copyBits. wideString restoreEndianness. self assert: wideString = expectedWideString Hence it fixes loading/diffing MCZ with wide character. Mac OS Builds: Don't link with -fvisibility=hidden; it breaks external plugins. Use -fvisibility=default instead. This fixes e.g. UnixOSProcessPlugin on Mac OS X. Windows Builds: The Windows VMs are no longer "dpiAware". If you want one-to-one pixel mapping check the README for ins ructions. It's a simple edit. _,,,^..^,,,_ best, Eliot

April 23, 2016

Re: [Pharo-dev] Class allSubInstances size takes 23 seconds to run on Pharo 5 on OS X

by Bernhard Pieber

Wow, thanks for the detailed explanation! Cheers, Bernhard > Am 21.04.2016 um 16:48 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: > > Hi Bernhard, > >> On Apr 20, 2016, at 9:56 PM, Bernhard Pieber <bernhard(a)pieber.com> wrote: >> >> Hi Eliot, >> >> Right, but in the latest Squeak5.1-trunk with the latest CogSpur.r3663.app it takes only 3 milliseconds. I guess itâs just an optimized implementation, there. (Canât look right now.) > > Indeed ;-). In most Smalltalk implementations an object's header contains a direct reference (a pointer) to its class, but in Spur, an object's header contains a "class index" (as does the Dart VM). IIRC this is an approach first tried in a system at Xerox PARC, but what follows, I invented for 64-bit VW, to avoid having 64-bits of class reference in every object. > > The object header contains both a 22-bit classIndex, for up to 4 million classes, and a 22-bit identityHash field for 4 million hash values. The classIndex is used in all method caches, which has advantages for the GC, and means that when sending a message via an inline cache, the object's index is fetched, not its class. > > Classes are stored in a hidden two-level sparse array (array of arrays), the class table. If the object's class object is required (for the #class message or to do a full message lookup searching the inheritance hierarchy) the classIndex is used to index the class table. > > The classes known to the VM, Array, Message, Context, LargeNegativeInteger, LargePositiveInteger have known indices and occupy the first page of the class table. So the VM can allocate instances of these by simply writing a header containing the relevant classIndex. A conventional implementation would have to fetch the class from the specialObjectsArray and write it into the header (and in pre-Spur, there are 31 "compact class indices" of which a handful are used for a subset of the classes). > > But how does the VM find the classIndex of an arbitrary class? Searching the table would be very slow. So Spur arranges that a class's identityHash is also its index in the classTable. Classes have their own special identityHash primitive, see Behavior>>#identityHash. Whenever the VM tries to Instantiate a class, or whenever the class's identityHash primitive is run, if the class's identityHash is zero, the VM assigns an unused index in the class table as the identityHash and stores the class in the table. So a class's identityHash is its index in the class table. > > To Instantiate a class its identityHash is copied into the classIndex field of the new instance's header. To search for all instances of a class, the VM searches for objects whose classIndex is that class's identityHash. A consequence is that if a class doesn't yet have an identityHash (identityHash = 0) it can't have instances, and so there is no need to scan the heap. > > > Note that you can't (easily) tell from the image. If you send identityHash to a class that will enter it into the table. There's a hidden hasIdentityHash primitive that can be used, and if you're curious I can post code to get at it. Note that this implies all the metaclasses are in the table because they have as their single instance a normal named class, but Metaclasses holds onto its instance via thisClass and so can also avoid traversing the heap. > > Some things to try: > > {Array. ByteString. Character. Context. LargeNegativeInteger. LargePositiveInteger. Message. SmallFloat64. BoxedFloat64. SmallInteger} collect: #identityHash > > and in a pre-Spur system > > Smalltalk compactClassesArray select: [:c| Smalltalk specialObjectsArray includes: c] thenCollect: [:c| {c. c indexIfCompact] > > Hope this explains what's going on under the covers. > >> Cheers, >> Bernhard >> >>> Am 20.04.2016 um 17:43 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: >>> >>> Hi Bernhard, >>> >>> >>>> On Apr 20, 2016, at 5:26 AM, Bernhard Pieber <bernhard(a)pieber.com> wrote: >>>> >>>> Dear Pharoers, >>>> >>>> I found something strange: >>>> Time millisecondsToRun: [ Class allSubInstances size ]. â23617" >>> >>> Because it does an allInstances for Class and all its subclasses, and allInstances visits every object in the heap, so this does thousands of scans of the heap. >>> >>> >>>> I did this on a new Pharo 5 image >>>> curl get.pharo.org/alpha+vmLatest | bash >>>> >>>> Can somebody confirm this on their machine? What might be the reason? >>>> >>>> Cheers, >>>> Bernhard >> >> >

April 23, 2016

Re: [Pharo-dev] Collection with spatiotemporal indexation - Ideas and discussions ?

by Robert Withers

Hi CÃ©drik, Have you considered seeing if there are any Voronoi diagram packages in one of the repositories? I believe there is a fair bit of research into algorithms. You search use of spaciotemporal collated data sounds very interesting and there is a segment on computation over segments in this slide deck, that might be something, I don't know: http://graphics.stanford.edu/courses/cs368-06-spring/handouts/Delaunay_2.pdf. Certainly there is utility on the graphics side to use a 4D quadratic model (with GPU accel) and may well be modeled already in squeak/Pharo. Would't that be something! Regards, Robert On 04/23/2016 01:29 PM, CÃ©drick BÃ©ler wrote: > Hi Esteban, > > Thanks a lot, I think Iâll try your History package, it seems to be a very good starting point (instead of hacking it myself). > Iâll try it soon. > > Thanks for all the information ;) > > Cheers, > > CÃ©drik > > >> Le 23 avr. 2016 Ã 18:28, Esteban A. Maringolo <emaringolo(a)gmail.com> a Ã©crit : >> >> Maybe instead of having a Dictionary, you can use my History package [1]. >> It allows you to add elements to "the history", and the History class >> will provide certain "lookup" strategies depending on how you want to >> query it. >> >> It is a trimmed down version of an utility class I used for years in >> commercial products where the History contained thousands of elements. >> This version uses linear search, my previous implementation used >> binary search which was significantly faster with lots of elements in >> the collection. >> >> Of course it doesn't solve your spatial queries needs, I don't know if >> there is something in Smalltalk for that other than the distance >> between two coordinates[2], PostgreSQL 9.2 has some support for >> "temporal" data/tables which you could combine with PostGIS if you >> need to combine a spatial query with a temporal one [3]. >> >> Regards, >> >> [1] http://www.smalltalkhub.com/#!/~emaringolo/History >> [2] http://pastebin.com/ThKDXCKK >> [3] http://clarkdave.net/2015/02/historical-records-with-postgresql-and-tempora… >> Esteban A. Maringolo >> >> >> 2016-04-23 12:13 GMT-03:00 CÃ©drick BÃ©ler <cdrick65(a)gmail.com>: >>> >>> Sure, but 1) that's not a lot >>> >>> 2) do you even know if you need interactive stuff or if batch processing is >>> ok? >>> >>> >>> interactive I would sayâ¦ but hard to be certain right now as it depends on >>> design choicesâ¦ do we cache ? do we aggregate past data ? extra indexes ? >>> Iâll see later. >>> I want something simple, keep everythingâ¦ and query according to time >>> interval, areas (contexts)â¦ >>> >>> But yes for now this is pointless to look for something optimal and Iâll use >>> a dictionary as it will be small at start. >>> >>> Cheers, >>> >>> CÃ©drik >>> >>> >>> >>> >>> -- >>> Damien Pollet >>> type less, do more [ | ] http://people.untyped.org/damien.pollet >>> >>> > -- Robert . .. ... ^,^

April 23, 2016

Re: [Pharo-dev] Collection with spatiotemporal indexation - Ideas and discussions ?

by Alistair Grant

On Sat, Apr 23, 2016 at 02:13:22PM +0200, CÃ©drick BÃ©ler wrote: > Hi Alistair, > > Thanks, this sounds like a nice suggestion. > > I have to think about it. > Adding altitude would be also interesting in some cases but not as a start > (quite limited usage). > > When you say to package it separately, youâre talking about Geolocation, > Spatiotemporal classes ? or also the collection ? My impression was that the Geolocation & Spatiotemperal classes already exist (and presumably are already packaged), so I was thinking of the collection class (which would have the geolocation and spatiotemperal as dependencies). > I can try something but I think this will deserve more Â« computational > thinking Â» power than I have ^^ Me too, but having something is still better than nothing, and maybe someone will provide ideas for improvements. Cheers, Alistair

April 23, 2016