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
> 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
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.
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.
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
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:
Status: Accepted
Owner: camillob...(a)gmail.com
Labels: Type-Defect Priority-Medium
New issue 99 by camillob...(a)gmail.com: Link LZ4 Compression
http://code.google.com/p/cog/issues/detail?id=99
We should build our VM with lz4 support:
https://code.google.com/p/lz4/
Ideally we will compress all internal unused/static data.
Another application would be to compress all the fuel-ized data as well.
Status: Accepted
Owner: siguc...(a)gmail.com
Labels: Type-Defect Priority-Medium
New issue 97 by siguc...(a)gmail.com: Sound on Linux
http://code.google.com/p/cog/issues/detail?id=97
... I had to replace the vm-sound-ALSA plugin that comes bundled in the 1.4
one-click image with the so.vm-sound-ALSA one that comes in Squeak 4.3.
Couldn't we include that one by default? The one that comes with Pharo
doesn't work and reports "could not find module vm-sound-ALSA".
...
Looks like run-time link problems, because code we use for this plugin is
same.