Vm-dev November 2012

vm-dev@lists.squeakfoundation.org

24 participants
73 discussions

ffi-test-main.c fails on FreeBSD
by Gary Dunn 12 Aug '16

12 Aug '16

In conjunction with getting Open Cobalt running on FreeBSD I have been looking into the problems with SqueakFFIPrims on FreeBSD and have reached a point that is beyond my understanding. I am not sure if the fix should come from the VM side or the FreeBSD port maintainer. I needed to get source code back into the ports tree so I did a make in /usr/ports/lang/squeak. I already had the 3.9 tarball, so that just repopulated the source and did the initial build. In the "files" folder I found patch files typical for a FreeBSD port. These patch source files from a generic tarball to work with FreeBSD. The one of interest was patch-platforms__unix__plugins__SqueakFFIPrims__ffi-config which contains ----x-----x----- --- platforms/unix/plugins/SqueakFFIPrims/ffi-config.org Wed Apr 26 20:27:53 2006 +++ platforms/unix/plugins/SqueakFFIPrims/ffi-config Wed Apr 26 20:29:00 2006 @@ -39,6 +39,7 @@ case ${abi} in linux) abi=sysv;; + freebsd*) abi=sysv;; darwin*) abi=darwin;; *) abi=libffi; lib="-lffi";; esac -----x-----x----- I then had the folder work/Squeak-3.9-7/platforms/unix/plugins/SqueakFFIPrims In it is a file 00README which explains how to test FFI. It says to run ffi-test-config but I have no such file. It says to type "make" to build a test suite but the build failed. It says to try with make CPU=any ABI=libffi LIB=-lffi which also failed. I traced the problem to the gcc search paths for includes and libraries -- turns out FreeBSD only searches /usr/include and /usr/lib when the required files are in /usr/local/include and /usr/local/lib. After some fiddling I finally had a "main" to test. It failed: ffi-test-main.c failed at line 361. Here is a bit from that file, ending with line 361: ffiInitialize(); for (ul= 0; ul < 15; ++ul) ffiPushSingleFloat(fa[ul]); GO(FFITypeSingleFloat, many); f= ffiReturnFloatValue(); ffiCleanup(); CHECK(f - ff < FLT_EPSILON); I worked out the CHECK macro but could not find what FLT_EPSILON is. At that point I decided to stop and come to you for help. Where do I go from here? -- Gary Dunn, Honolulu osp(a)aloha.com http://openslate.net/ http://e9erust.blogspot.com/ Sent from Slate001

5 8

Do we have the new primitive?? [WAS] Re: [Pharo-project] IdentitySet but using #hash rather than #identityHash ?
by Mariano Martinez Peck 16 Dec '15

16 Dec '15

> All I can say is that I am impressed by the numbers it is really much >> faster. >> I still don't understand why I send this email with a subject say >> IdentitySet because what I really need is a fast/large IdentityDictionary >> :( Anyway, there's a place where we can use this LargeIdentitySet in Fuel >> I think). >> >> So Levente, you say this is not possible to adapt this for dictionary? >> can >> we contact Eliot to provide such a primitive? >> > > As promised, I uploaded my LargeIdentityDictionary implementation to > http://leves.web.elte.hu/**squeak/**LargeIdentityDictionary.st<http://leves.web.elte.hu/squeak/LargeIdentityDictionary.st>. > The numbers will be a bit worse compared to LargeIdentitySet, because of > the lack of the primitive, but it's still 2-3x faster than other solutions > (IdentityDictionary, PluggableIdentityDictionary, subclassing, etc). I'm > about to propose this primitive with other improvements on the vm-dev list. > > Hi Eliot/Levente. What is the status of this? Do we have already the new primitive? If true, how can we adapt LargeIdentitySet to use such new primitive? Thanks! > > Levente > > >> thanks >> >> On Fri, Dec 16, 2011 at 3:28 PM, Levente Uzonyi <leves(a)elte.hu> wrote: >> >> On Fri, 16 Dec 2011, Henrik Sperre Johansen wrote: >>> >>> On 16.12.2011 03:26, Levente Uzonyi wrote: >>> >>>> >>>> >>>>> How about my numbers? :) >>>>> >>>>> "Preallocate objects, so we won't count gc time." >>>>> n := 1000000. >>>>> objects := Array new: n streamContents: [ :stream | >>>>> n timesRepeat: [ stream nextPut: Object new ] ]. >>>>> >>>>> set := IdentitySet new: n. >>>>> Smalltalk garbageCollect. >>>>> [1 to: n do: [ :i | set add: (objects at: i) ] ] timeToRun. "4949" >>>>> >>>>> set := LargeIdentitySet new. >>>>> Smalltalk garbageCollect. >>>>> [1 to: n do: [ :i | set add: (objects at: i) ] ] timeToRun. "331" >>>>> >>>>> set := (PluggableSet new: n) >>>>> hashBlock: [ :object | object identityHash * 4096 + object class >>>>> identityHash * 64 ]; "Change this to #basicIdentityHash in Pharo" >>>>> equalBlock: [ :a :b | a == b ]; >>>>> yourself. >>>>> Smalltalk garbageCollect. >>>>> [1 to: n do: [ :i | set add: (objects at: i) ] ] timeToRun. "5511" >>>>> >>>>> >>>>> I also have a LargeIdentityDictionary, which is relatively fast, but >>>>> not >>>>> as fast as LargeIdentitySet, because (for some unknown reason) we don't >>>>> have a primitive that could support it. If we had a primitive like >>>>> primitive 132 which would return the index of the element if found or >>>>> 0 if >>>>> not, then we could have a really fast LargeIdentityDictionary. >>>>> >>>>> >>>>> Levente >>>>> >>>>> Hehe yes, if writing a version fully exploiting the limited range, >>>> that's >>>> probably the approach I would go for as well. >>>> (IAssuming it's the version at http://leves.web.elte.hu/** >>>> squeak/LargeIdentitySet.st<htt**p://leves.web.elte.hu/squeak/** >>>> LargeIdentitySet.st<http://leves.web.elte.hu/squeak/LargeIdentitySet.st> >>>> > >>>> ) >>>> >>>> Mariano commented in the version at http://www.squeaksource.com/** >>>> FuelExperiments <http://www.squeaksource.com/**FuelExperiments<http://www.squeaksource.com/FuelExperiments>> >>>> that it's >>>> >>>> slow for them, which I guess is due to not adopting #identityHash calls >>>> to >>>> #basicIdentityHash calls for Pharo: >>>> ((0 to: 4095) collect: [:each | each << 22 \\ 4096 ]) asSet size -> 1 >>>> So it basically uses 1 bucket instead of 4096... Whoops. :) >>>> >>>> Uploaded a new version to the MC repository which is adapted for Pharo, >>>> on the same machine my numbers were taken from, it does the same test >>>> as I >>>> used above in 871 ms. (181 with preallocation). >>>> >>>> >>> Cool. One more thing: in Squeak the method using primitive 132 directly >>> was renamed to #instVarsInclude:, so now #pointsTo: works as expected. If >>> this was also added to Pharo, then the #pointsTo: sends should be changed >>> to #instVarsInclude:, otherwise Array can be reported as included even if >>> it wasn't added. >>> I'll upload my LargeIdentityDictionary implementation to the same place >>> this evening, since it's still 2-3 factor faster than other solutionts >>> and >>> there seem to be demand for it. >>> >>> >>> Levente >>> >>> >>> Cheers, >>>> Henry >>>> >>>> >>>> >>>> >>> >> >> -- >> Mariano >> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >> >> > -- Mariano http://marianopeck.wordpress.com

4 12

Issue 108 in cog: Access to stackPages broken in Stack/CoInterpreter>>#commonReturn
by cog＠googlecode.com 08 Aug '13

08 Aug '13

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 108 by stm...(a)gmail.com: Access to stackPages broken in Stack/CoInterpreter>>#commonReturn http://code.google.com/p/cog/issues/detail?id=108 One of the branches in Stack/CoInterpreter>>#commonReturn does a `self freeStackPage: thePage` where all other places in the code do `stackPages freeStackPage: thePage`. #freeStackPage: is not defined on self, so I suppose the attached patch is necessary. The bug should be in the CogVM branch and the Pharo branches of the codebase. Attachments: StackPages Access.1.cs 11.5 KB

1 1

Issue 107 in cog: Bit-rot in the Pharo CogVM code based (Simulator)
by cog＠googlecode.com 08 Aug '13

08 Aug '13

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 107 by stm...(a)gmail.com: Bit-rot in the Pharo CogVM code based (Simulator) http://code.google.com/p/cog/issues/detail?id=107 The attached change set fixes bit rot in the *InterpreterSimulator and related classes. Here a brief summary: - VMClass>>#doOrDefer: now uses ProcessBrowser>>#isUIProcess: instead of Project - it replaces the use of #asDisplayText with StringMorph>>#contents:. - use of ThreadStream>>#on: is replaced with ThreadSafeTranscript>>#new - Utilities is replaced by UIManager>>#default - and #primitiveGetAttribute now uses the non-depricated `Smalltalk vm getSystemAttribute: attr` Attachments: Fix simulator.3.cs 30.0 KB

1 1

Issue 106 in cog: Bit-rot in NOMS>>#sqGrowMemory:By: and IS>>#ioUTCMicrosecondsNow
by cog＠googlecode.com 08 Aug '13

08 Aug '13

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 106 by stm...(a)gmail.com: Bit-rot in NOMS>>#sqGrowMemory:By: and IS>>#ioUTCMicrosecondsNow http://code.google.com/p/cog/issues/detail?id=106 In InterpreterSimulator the method #ioUTCMicrosecondsNow is missing. I just added this: ioUTCMicrosecondsNow "STEFAN: not entierly sure what to do with this... but the method is missing." ^ Time millisecondClockValue In the NewObjectMemorySimulator>>#sqGrowMemory:By:, there is a reference to coInterpreter which receives are #memory: message. However in the new hierarchy, where the interpreter is not an ObjectMemory anymore, that message is not implemented. So, I removed it... Not sure whether either of these solutions is appropriate, but would be good to get the problems fixed and have the simulators usable. Attachments: more-bit-rot.1.cs 857 bytes

1 1

Issue 105 in cog: Add VMMaker Smalltalk Sources to the C Repository
by cog＠googlecode.com 08 Aug '13

08 Aug '13

Status: Accepted Owner: camillob...(a)gmail.com Labels: Type-Defect Priority-Medium New issue 105 by camillob...(a)gmail.com: Add VMMaker Smalltalk Sources to the C Repository http://code.google.com/p/cog/issues/detail?id=105 Currently there is no way to find out which VMMaker version works along with which C source version. Solution: Export the current VMMaker sources to the repository and keep them in sync there.

1 1

Issue 104 in cog: Remove KLATT Plugin
by cog＠googlecode.com 08 Aug '13

08 Aug '13

Status: Accepted Owner: camillob...(a)gmail.com Labels: Type-Defect Priority-Medium New issue 104 by camillob...(a)gmail.com: Remove KLATT Plugin http://code.google.com/p/cog/issues/detail?id=104 I wonder who still wants to use this. Klatt is sincerely outdated, every OS provides better speech synthesis nowadays.

1 1

Re: Issue 102 in cog: Can't allocate semaphores? VirtualMachine>>maxExternalSemaphores: aSize | Not enough space for external objects, set a larger size at startup!
by cog＠googlecode.com 08 Aug '13

08 Aug '13

Comment #18 on issue 102 by marcus.d...(a)gmail.com: Can't allocate semaphores? VirtualMachine>>maxExternalSemaphores: aSize | Not enough space for external objects, set a larger size at startup! http://code.google.com/p/cog/issues/detail?id=102 Moved to: Issue cog:102

1 2

Issue 101 in cog: Snapshot primitive with 512byte image header
by cog＠googlecode.com 08 Aug '13

08 Aug '13

Status: Accepted Owner: camillob...(a)gmail.com Labels: Type-Defect Priority-Medium New issue 101 by camillob...(a)gmail.com: Snapshot primitive with 512byte image header http://code.google.com/p/cog/issues/detail?id=101 I would like to add proper shebang support to our image files. Hence I need a proper primitive which allows me to inject the 512bytes header with a proper shebang (or other user data..) This could be handled the same way as the quit primitive by checking for an optional argument, the header, and pass it along to #writeImageFile:

3 3

Re: Issue 100 in cog: so.vm-sound-ALSA for pharo linux vm
by cog＠googlecode.com 08 Aug '13

08 Aug '13

Comment #1 on issue 100 by camillob...(a)gmail.com: so.vm-sound-ALSA for pharo linux vm http://code.google.com/p/cog/issues/detail?id=100 Moved to: Issue cog:100

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev November 2012