Vm-dev April 2014

vm-dev@lists.squeakfoundation.org

39 participants
112 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

bug on windows ioShowDisplay for bitdepth 16/8/4 (big endian)
by Nicolai Hess 11 May '14

11 May '14

There is still something wrong with byte/word swap in windows ioShowDisplay code attached are two screenshots squeak 4.5 image with cogvm from http://files.pharo.org/vm/cogmt/win/ pharo 30793 image with latest vm from http://files.pharo.org/vm/pharo/win/ showing this bug after setting the Display depth to 16 (Display newDepth:16) sqwin32window.c has three variants for doing the byte_swap/word_swap on bitdepths with big endian to convert to lsb This one is active and causes this error. # if __GNUC__ >= 3 # define BYTE_SWAP(w) __asm__("bswap %0" : "=r" (w) : "r" (w)) # define WORD_SWAP(w) __asm__("roll $16, %0" : "=r" (w) : "r" (w)) This one would work # else # define BYTE_SWAP(w) __asm__("bswap %%eax" : "=eax" (w) : "eax" (w)) # define WORD_SWAP(w) __asm__("roll $16, %%eax" : "=eax" (w) : "eax" (w)) This one, of course, works too # else # define BYTE_SWAP(w) w = (w << 24) | ((w & 0xFF00) << 8) | ((w >> 8) & 0xFF00) | (w >> 24) # define WORD_SWAP(w) w = (( (unsigned)(w) << 16) | ((unsigned) (w) >> 16)) This one is not there but would work (at least with gcc > 4.5 # define BYTE_SWAP_MY(w) __asm__("bswap %0" : "+r" (w)) # define WORD_SWAP_MY(w) __asm__("roll $16, %0" : "+r" (w)) But actually I don't know assembler and/or the gcc inline code syntax, so I don't know what is wrong with the first version :) Nicolai btw, you can not test this bug with the current squeak 4.5 all in on image, as it uses a rather old vm. Third screenshot: using the latest stable pharo-vm, it looks much more wrong, as there was another(?) bug that is fixed already(?) - i don't know :)

4 8

Suspect single float types
by Nicolas Cellier 05 May '14

05 May '14

I read in CCodeGenerator>>computeKernelReturnTypes fetchFloatAt:into: #float storeFloatAt:from: #float fetchFloatAtPointer:into: #float storeFloatAtPointer:from: #float fetchSingleFloatAt:into: #float storeSingleFloatAt:from: #float fetchSingleFloatAtPointer:into: #float storeSingleFloatAtPointer:from: #float Ain't these #double?

2 2

Help needed to compile a fresh Mac Carbon VM
by David T. Lewis 01 May '14

01 May '14

VM hackers and Mac enthusiasts, we need your help. Here is your chance to earn big karma points, along with the grateful admiration of the your peers. What we need: A freshly compiled Mac Carbon VM, just like the Squeak 4.2.5beta1U VM on http://squeakvm.org/mac, but updated to use current VM sources, and to include CameraPlugin and ScratchPlugin. Why we need it: See below. We have a GSOC project mentor who needs to do work on a Mac, who needs to run an image format 6502 (pre-closure) image, and is running into problems related to the outdated Mac VM. We need an update to the Mac VM so that the GSOC project can proceed, and to prevent problems like this for other Mac users who need to be able to run older images (Etoys, Scratch, etc). http://www.google-melange.com/gsoc/project/details/google/gsoc2014/positive… If you have the ability to compile a Mac Carbon VM and make it available to the community, then please speak up. We need your help. (Cross posted to several lists, but discussion should go to vm-dev if possible) Thanks in advance, Dave On Thu, Apr 24, 2014 at 07:55:33PM -0400, Steve Thomas wrote: > David, > > I really appreciate the help and prompt reply. > > I checked and it does work under a previous version of OSX (10.7.2) > > Cheers, > Stephen > > > On Thu, Apr 24, 2014 at 5:01 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > > > Hi Steve, > > > > I am not a Mac user but I do work with the Squeak VM so I would like to > > help if I can. > > > > Just for my understanding - the camera works on older versions of OSX, but > > not on your OSX 10.9.2, is that correct? > > > > The camera plugin, which is required for using the camera in Etoys, was > > added to the Mac VM after the VM was originally built. The plugin was > > compiled somewhat differently from the other plugins in the VM, which may > > account for it working on one version of OS X and not on another. > > > > If that is the case, then we may need to find a volunteer to rebuild the > > VM with all necessary plugins included. I am not a Mac expert at all, but > > I think that is the likely source of the difficulty. > > > > Unfortunately we have been short handed on Mac support for the VM, but if > > you can confirm that this is the kind of problem that you are seeing, I > > can put out a call for help on the vm-dev list and see if we can find a > > volunteer do the necessary update. > > > > Thanks, > > > > Dave > > > > > I downloaded latest software using "update code from server" and still no > > > luck. > > > > > > > > > > > > > > > Need this for Google Summer of Code project I will be mentoring > > > > > http://www.google-melange.com/gsoc/project/details/google/gsoc2014/positive… > > > < > > http://www.google-melange.com/gsoc/project/details/google/gsoc2014/positive… > > > > > > > > > Cheers, > > > Stephen > > > _______________________________________________ > > > etoys-dev mailing list > > > etoys-dev(a)squeakland.org > > > http://lists.squeakland.org/mailman/listinfo/etoys-dev > > > > >

2 2

Pharo 3.0 Released!
by Esteban Lorenzano 01 May '14

01 May '14

Dear World, Pharo 3.0 (http://www.pharo.org) is here. The past year seemed short as we got busy building more than usual. Many things have changed in Pharo. Here are the highlights: - The new modular Opal compiler is now the default compiler used in the system. - The Athens vector graphics canvas is now integrated and it supports Cairo rendering on all platforms. - Many tools have been rewritten using Spec, a new framework for building user interfaces. - Versionner and Kommiter are two of the new development tools. - RPackage, a new package mechanism got enhanced with tags and is fully integrated in the system. - The debugger model was rewritten to become modular, the inspector received a bump to support multiple views, and the Nautilus code browser supports tags, search and lot more improvements. - Morphic has seen many cleanings and improvements and the visual theme has been revamped. These are just the more prominent highlights, but the details are just as important. We have closed 2364 issues in Pharo 3 (compared with 1727 issues in Pharo 2). Take a moment to go through a more detailed recount of the progress: https://github.com/pharo-project/ChangeLogs/blob/master/Pharo30ChangeLogs.md Pharo is improving on many fronts. Just take a look at the code city of Pharo (built with Pharo for Pharo). Every building is a class, and the red bricks represent the modified methods in Pharo 3. Many things are changing but the system gets more stable. Moving from Pharo 2 to Pharo 3 is almost a matter of just loading the code. Remember that Pharo is your platform. We thank all the contributors of this release: Jean-Baptiste Arnaud, Simon Allier, Philippe Back, Clément Bera, Alexandre Bergel, Torsten Bergmann, Usman Bhatti, Vincent Blondeau, Noury Bouraqadi, Johan Brichau, Camillo Bruni, Sven Van Caekenberghe, Damien Cassou, Nicolas Cellier, Guido Chari, Dimitris Chloupis, Bernardo Contreras, Ben Coman, Gabriel Omar Cotelli, Jordi Delgado, Tommaso Del Sasso, Gisela Decuzzi, Christophe Demarey, Sean DeNigris, Marcus Denker, Martin Dias, Erwan Douaille, Stephane Ducasse, Stephan Eggermont, Pablo Estefo, Luc Fabresse, Johan Fabry, Hilaire Fernandes, Nahuel Garbezza, Leo Gassman, Lucas Giudice, Tudor Girba, Thierry Goubier, Norbert Hartl, Dale Henrichs, Pablo Herrero, Nicolai Hess, Andre Hora, Alejandro Infante, Ricardo Jacas, Henrik Sperre Johansen, Denis Kudryashov, Pavel Krivanek, Juraj Kubelka, Laurent Laffont, Jannik Laval, Max Leske, David Lewis, Diego Lont, Esteban Lorenzano, Stefan Marr, Mariano Martinez Peck, Roberto Minelli, Hernan Morales Durand, Eliot Miranda, Fernando Olivero, Nicolas Papagna Maldonado, Nick Papoylias, Nicolas Passerini, Vanessa Peña, Nicolas Petton, Alain Plantec, Guillermo Polito, Damien Pollet, Jochen Rick, Benjamin Van Ryseghem, Ronie Salgado, Camille Teruel, Juan Pablo Sandoval Alcocer, Samir Saleh, Frank Shearar, Igor Stasenko, Aliaksei Syrel, Sebastian Tleye, Yuriy Tymchuk, Andres Valloud, Martin Walk, Hernan Wilkinson. And many many more who contributed indirectly, by reporting bugs, participating in discussion threads, providing feedback... Pharo 3.0 is the largest step we took since we started. Yet, it’s just a step. Expect more. Much more. Enjoy! The Pharo Team

3 2

Re: [Vm-dev] FT2Plugin for Freetype: Freetype-Plugin-dtl.71.mcz
by David T. Lewis 30 Apr '14

30 Apr '14

I think that I screwed up the MC parenting for this, sorry for that. My intent is to temporarily bypass Freetype-Plugin-eem.70 until compilation issues can be resolved. Freetype-plugin-dtl.71.mcz (this update) is identical to FreetypePlugin-eem.69.mcz. The updates in Freetype-Plugin-eem-70.mcz do not yet compile in VMM trunk, and the plugin has been excluded from oscog, so the Freetype-Plugin-eem70.mcz changes should be reapplied when those issues are resolved. Sorry for the confusion, I should pay closer attention when the Adopt button in the MC browser says "do not do this unless you know what you are doing". Dave On Wed, Apr 30, 2014 at 03:07:32AM +0000, squeak-dev-noreply(a)lists.squeakfoundation.org wrote: > > Dave Lewis uploaded a new version of Freetype-Plugin to project FT2Plugin for Freetype: > http://www.squeaksource.com/FreetypePlugin/Freetype-Plugin-dtl.71.mcz > > ==================== Summary ==================== > > Name: Freetype-Plugin-dtl.71 > Author: dtl > Time: 29 April 2014, 10:02:21.108 pm > UUID: 6329a996-8fa7-4097-bed4-f1e62c9a1445 > Ancestors: Freetype-Plugin-eem.70 > > Temporarily hold back Freetype-Plugin-eem.70, to be reapplied when compilation issues are resolved. Updates through Freetype-Plugin-eem.69 compile cleanly in VMM trunk, changes for Cog are on hold as per: > > Name: VMMaker.oscog-eem.687 > Author: eem > Time: 28 April 2014, 2:56:03.445 pm > UUID: 501501b0-dad7-4305-b25e-96ed74c92fd2 > Ancestors: VMMaker.oscog-eem.686 > > Fix source paths in the Squeak VM config. Exclude the > FT2Plugin; it's not robust enough to load and generate yet.

1 0

FT2Plugin for Freetype: Freetype-Plugin-dtl.71.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 30 Apr '14

30 Apr '14

Dave Lewis uploaded a new version of Freetype-Plugin to project FT2Plugin for Freetype: http://www.squeaksource.com/FreetypePlugin/Freetype-Plugin-dtl.71.mcz ==================== Summary ==================== Name: Freetype-Plugin-dtl.71 Author: dtl Time: 29 April 2014, 10:02:21.108 pm UUID: 6329a996-8fa7-4097-bed4-f1e62c9a1445 Ancestors: Freetype-Plugin-eem.70 Temporarily hold back Freetype-Plugin-eem.70, to be reapplied when compilation issues are resolved. Updates through Freetype-Plugin-eem.69 compile cleanly in VMM trunk, changes for Cog are on hold as per: Name: VMMaker.oscog-eem.687 Author: eem Time: 28 April 2014, 2:56:03.445 pm UUID: 501501b0-dad7-4305-b25e-96ed74c92fd2 Ancestors: VMMaker.oscog-eem.686 Fix source paths in the Squeak VM config. Exclude the FT2Plugin; it's not robust enough to load and generate yet.

1 0

About FreeType in Squeak4.5
by Nicolas Cellier 30 Apr '14

30 Apr '14

Hi Eliot, seeing these 2 lines in BuildSqueak45Image.st "('http://www.squeaksource.com/FreeTypePlus' 5 ('FreeType')) can't load this. it is toxic to Squeak 4.5" ('http://www.squeaksource.com/FreetypePlugin' 8 ('Freetype-Plugin')) that reminds me i have opened an alternate repository not toxic for Squeak 4.x : MCHttpRepository location: 'http://ss3.gemstone.com/ss/FreeTypePlus' user: '' password: '' cheers Nicolas

3 4

[ANN] FFI for ARM
by Douglas McPherson 30 Apr '14

30 Apr '14

I’ve published an alpha version of an FFI for the ARM architecture. It is in the class ThreadedARMFFIPlugin in the VMMaker.oscog package on source.squeak.org. The generated sources are also available at http://squeakvm.org/svn/squeak/branches/Cog/src/plugins/SqueakFFIPrims/ARM3… It passes all existing FFI tests and all tests I used for development. I plan to commit my development tests to the FFI-Tests package within the next few days. These extra tests are important because existing tests don’t exercise some of the trickier cases choosing between registers and stack when marshaling function parameters. So far, the ARM FFI has only been tested with the Cog/Stack VM on a Raspberry Pi. I plan to also test it on the BeagleBone Black which has a slightly different ARM chip. The overwhelming majority of the credit for this must go to Eliot Miranda because his FFI design works so well, and because he helped me immensely along the way. And many thanks to Tim Rowledge for showing me how to build a Cog/Stack VM on the RPi and answering numerous other questions. Any bugs in the ARM version of the FFI are my responsibility. Enjoy! Doug

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev April 2014