Vm-dev September 2012

vm-dev@lists.squeakfoundation.org

26 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

Re: Issue 98 in cog: SSL plugin not recognized - latest vm and latest Pharo-2.0
by cog＠googlecode.com 08 Aug '13

08 Aug '13

Comment #4 on issue 98 by camillob...(a)gmail.com: SSL plugin not recognized - latest vm and latest Pharo-2.0 http://code.google.com/p/cog/issues/detail?id=98 Moved to: Issue cog:98

1 2

Issue 97 in cog: Sound on Linux
by cog＠googlecode.com 08 Aug '13

08 Aug '13

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.

1 4

Issue 96 in cog: Using >> (bitShift:) instead of pow (raisedTo:)
by cog＠googlecode.com 08 Aug '13

08 Aug '13

Status: Accepted Owner: nicolas....(a)gmail.com Labels: Type-Enhancement Priority-Low New issue 96 by nicolas....(a)gmail.com: Using >> (bitShift:) instead of pow (raisedTo:) http://code.google.com/p/cog/issues/detail?id=96 By virtue of SLANG translation, interpreterAllocationReserveBytes uses pow((double)2,(double)n) to answer an int, wouldn't it better to just use a bit shift? 2^n <=> 1<<n, up to n=31 I doubt we reserve more than that, the result is signed anyway. And this would remove yet another warning. Attachments: interpreterAllocationReserveBytes.st 2.0 KB

1 1

Re: Issue 72 in cog: Don't open an Dialog on Mac in headless mode
by cog＠googlecode.com 08 Aug '13

08 Aug '13

Updates: Status: Accepted Cc: esteba...(a)gmail.com Comment #1 on issue 72 by sean.p.d...(a)gmail.com: Don't open an Dialog on Mac in headless mode http://code.google.com/p/cog/issues/detail?id=72 This is even more important now with the MBP retina. A "headless" cog image always forces the GPU to discrete mode, draining the battery. I often use headless (e.g. for Jenkins jobs and web scrapers) and in addition to the distraction of the unneeded window popping up, the switch to the power hogging GPU for no reason is even more of a drag.

1 1

Re: Issue 92 in cog: 3 LargeInteger arithmetic primitive bugs with minimum signed 64 bit value
by cog＠googlecode.com 12 Mar '13

12 Mar '13

Comment #6 on issue 92 by nicolas....(a)gmail.com: 3 LargeInteger arithmetic primitive bugs with minimum signed 64 bit value http://code.google.com/p/cog/issues/detail?id=92 As long as SmallInteger minVal negated (2^30) fits on 32 bits, there would be no such problem in SmallInteger primitives. AFAICT, 0 - INT_MIN like problem was only in LargeInt primitives, and those are not jitted. However, JIT is clever and for example in genPrimitiveAdd avoid shifting the SmallInteger tag (genShiftAwaySmallIntegerTagsInScratchReg:), and just remove it from one of operands (genRemoveSmallIntegerTagsInScratchReg:) so as to directly produce a tagged integer. Thus, testing if the result fits in 31 bit SmallInteger, become as simple as testing for 32 bit overflow... Testing for overflow is much simpler than in C, see senders of #JumpOverflow: Note that genPrimitiveDivide use another strategy for testing overflow case of (SmallInteger minVal/-1).

1 1

[Cog] Stack (mis)alignment on windows
by Igor Stasenko 29 Sep '12

29 Sep '12

Hi, if i build a debug version of VM on windows , it spams me with this assertion failed in debug console window: (getfp() & STACK_ALIGN_MASK) == STACK_FP_ALIGN_BYTES 41946 .... what is this number '41946', which follows? sometimes it is 42015 (and sometimes other), but most of times it's 41946. Actual question, how i can instruct gdb to break on a first failure of this assertion, so i can catch who causing this (or at least get close to one who causing it).. P.S. the STACK_ALIGN_BYTES is 16 P.P.S. i wonder for how long this thing broken there, since we're not building/using debug version of VM that often. -- Best regards, Igor Stasenko.

3 3

VM Maker: CMakeVMMaker-IgorStasenko.181.mcz
by commits＠source.squeak.org 27 Sep '12

27 Sep '12

Igor Stasenko uploaded a new version of CMakeVMMaker to project VM Maker: http://source.squeak.org/VMMaker/CMakeVMMaker-IgorStasenko.181.mcz ==================== Summary ==================== Name: CMakeVMMaker-IgorStasenko.181 Author: IgorStasenko Time: 27 September 2012, 3:21:01.136 pm UUID: 16166fb5-8e1a-499d-bc00-e315bbbfcc11 Ancestors: CMakeVMMaker-EstebanLorenzano.180 - fix building cairo lib =============== Diff against CMakeVMMaker-EstebanLorenzano.180 =============== Item was changed: + CMCairoBundle subclass: #CMCairo - CMThirdpartyLibrary subclass: #CMCairo instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'CMakeVMMaker-Libs'! + + !CMCairo commentStamp: 'IgorStasenko 9/26/2012 14:30' prior: 0! + This is Cairo library config for building on MacOSX! Item was added: + CMThirdpartyLibrary subclass: #CMCairoBundle + instanceVariableNames: '' + classVariableNames: '' + poolDictionaries: '' + category: 'CMakeVMMaker-Libs'! + + !CMCairoBundle commentStamp: 'IgorStasenko 9/26/2012 16:14' prior: 0! + this is common superclass for defining settings for building cairo and accompanied libraries! Item was added: + ----- Method: CMCairoBundle class>>canonicalName (in category 'as yet unclassified') ----- + canonicalName + ^ nil! Item was added: + ----- Method: CMCairoBundle class>>supports: (in category 'as yet unclassified') ----- + supports: aConfig + "right now, Mac only" + ^ aConfig platformName = 'iOS'! Item was changed: + CMCairoBundle subclass: #CMLibPng - CMThirdpartyLibrary subclass: #CMLibPng instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'CMakeVMMaker-Libs'! Item was changed: + CMCairoBundle subclass: #CMPixman - CMThirdpartyLibrary subclass: #CMPixman instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'CMakeVMMaker-Libs'! Item was changed: + CMCairoBundle subclass: #CMPkgConfig - CMThirdpartyLibrary subclass: #CMPkgConfig instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'CMakeVMMaker-Libs'! !CMPkgConfig commentStamp: 'IgorStasenko 6/9/2012 21:48' prior: 0! this will build a pkg-config package, required to built cairo ! Item was changed: ----- Method: CPlatformConfig>>addThirdpartyLibrary: (in category 'thirdparty libs') ----- addThirdpartyLibrary: libName | libs lib | libs := self thirdpartyLibs. lib := libs + detect: [:each | each canonicalName = libName ] - detect: [:each | each canonicalName = libName and: [ each supports: self ] ] ifNone: [ nil ]. lib ifNil: [ lib := (CMThirdpartyLibrary named: libName config: self). "add dependencies first, so thirpartyLibs collection will be naturally dependency sorted" lib dependencies do: [:dep | self addThirdpartyLibrary: dep ]. libs add: lib ]. ^ lib!

1 0

Re: [Pharo-project] No GUI on MacOSX 10.5.8 using Cocoa VM
by Igor Stasenko 26 Sep '12

26 Sep '12

On 26 September 2012 05:13, Yanni Chiu <yanni(a)rogers.com> wrote: > On 25/09/12 11:33 AM, Yanni Chiu wrote: >> >> >> So any ideas? > > > I tried to build the CogVM. > - search for build instructions, blog post, etc. > - almost give up in frustration before discovering the process noted below > :) > - download the tar ball from: > > https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-VM/Architecture=32,OS=mac/ > - find and install cmake > - already had a C compiler installed > - the HOWTOBUILD file said: > cd build > cmake . > make > - the build path is hard coded so: yes, this is an unavoidable outcome of being able to specify custom paths by developer for sources/build directories.. they are written into directories.cmake file. Initially all paths there was relative, but since user can specify own (absolute) custom paths, there is no way how it can keep working using relative paths. You can edit this file, or you can just run an image placed in ./image subdirectory and rerun cmake files generation on you machine, so paths will be fixed automagically. > % mkdir -p Users/hudson/jenkins/workspace/Cog-VM/Architecture/32/OS/mac/ > % mv ~/src > Users/hudson/jenkins/workspace/Cog-VM/Architecture/32/OS/mac/cog > # where ~/src is the un-tar'ed tar ball from above > - run cmake and make again (sometimes had to remove CMakeCache.txt file) > - build fails at: > ==== > [ 77%] Building CXX object > CMakeFiles/CogVM.dir/Users/hudson/jenkins/workspace/Cog-VM/Architecture/32/OS/mac/cog/platforms/iOS/vm/Common/Classes/sqSqueakScreenAndWindow.m.o > In file included from > /Users/hudson/jenkins/workspace/Cog-VM/Architecture/32/OS/mac/cog/platforms/iOS/vm/Common/Classes/sqSqueakScreenAndWindow.m:44: > /Users/hudson/jenkins/workspace/Cog-VM/Architecture/32/OS/mac/cog/platforms/iOS/vm/OSX/SqueakOSXAppDelegate.h:46: > error: cannot find protocol declaration for ‘NSApplicationDelegate’ > make[2]: *** > [CMakeFiles/CogVM.dir/Users/hudson/jenkins/workspace/Cog-VM/Architecture/32/OS/mac/cog/platforms/iOS/vm/Common/Classes/sqSqueakScreenAndWindow.m.o] > Error 1 > make[1]: *** [CMakeFiles/CogVM.dir/all] Error 2 > make: *** [all] Error 2 > ==== > - the culprit is the line: > @interface SqueakOSXAppDelegate : sqSqueakAppDelegate > <NSApplicationDelegate> > - web search for NSApplicationDelegate > - find Apple dev page that says: > NSApplicationDelegate - Available in OS X v10.6 and later. > > So, is there an important reason to use NSApplicationDelegate? IIUC, it > results in the VM requiring OSX 10.6 or higher, which means my 10.5.8 will > never work with CogVM's built this way. > is there a reason why you cannot upgrade your OS? -- Best regards, Igor Stasenko.

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev September 2012