- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Moose-dev] I'm not getting it
by Tudor Girba Nov. 19, 2013

Nov. 19, 2013

It's not Moose related, but Athens related. There seems to be a problem with Athens and your Linux installation. I repost the question on the pharo mailing list. Anyone has an idea why this happens? Moose 4.9 runs on a Pharo 2.0 image. Cheers, Doru On Tue, Nov 19, 2013 at 12:22 PM, Friedrich Dominicus < frido(a)q-software-solutions.de> wrote: > I've a fresh installed Moose 4.9 here. If I'm trying ot open > Roassel Eazel I get an Backtrace > NativeBoostLinux32(Object)>>error: > NativeBoostLinux32>>getGlobalSymbolPointer: > NativeBoostLinux32>>loadSymbol:fromModule: > NativeBoost class>>loadSymbol:fromModule: > Metaclass(Object)>>nbGetSymbolAddress:module: > NBFFICallout>>generateCall:module: > NBFFICalloutAPI>>function:module: in Block: [:gen | gen callType: conv;... > NBFFICallout class(NBNativeCodeGen class)>>generateCode:andRetry: in > Block: [bytes := aBlock... > BlockClosure>>on:do: > NBRecursionDetect class>>in:during: > NBFFICallout class(NBNativeCodeGen class)>>generateCode:andRetry: > NBFFICallout class(NBNativeCodeGen class)>>handleFailureIn:nativeCode: > NBFFICalloutAPI>>function:module: > AthensCairoSurface class(Object)>>nbCall: > AthensCairoSurface class>>primImage:width:height: > AthensCairoSurface class>>extent:format: > AthensCairoSurface class>>extent: > ROAthensMorph>>extent: > ROAthensMorph(ROMorph)>>setView: > ROAthensMorph class(ROMorph class)>>on: > ROMorphWidgetFactory class>>forView:windowSized: > ROViewStack(ROView)>>openInWindowSized: > ROViewStack(ROView)>>open > ROMondrianViewBuilder>>open > UndefinedObject>>DoIt > Compiler>>evaluate:in:to:notifying:ifFail:logged: > Compiler class>>evaluate:for:notifying:logged: > Compiler class>>evaluate:for:logged: > Compiler class>>evaluate: > ROEaselMorphic>>openViewFor: in Block: [Compiler evaluate: str] > > > I checked my installation and the symbol is in > /usr/lib/i386-linux-gnu/libcairo.a > nm libcairo.a | grep cairo_image_surface_create > U INT_cairo_image_surface_create > U _cairo_image_surface_create_with_content > U INT_cairo_image_surface_create > 00000b30 T cairo_image_surface_create > > > Anywy even if I change > pathToCairoOnLinux > "On different flavors of linux the path to library may differ > depending on OS distro or whether system is 32 or 64 bit. > > " > #( > > '/usr/lib/i386-linux-gnu/libcairo.so.2' > '/usr/lib/libcairo.so.2' > > ) do: [ :path | > > path asFileReference exists ifTrue: [ ^ path ] > ]. > > ^ self cantFindCairoOnLinux > > It won't find this "symbol". What is going on? > > Regards > Friedrich > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- www.tudorgirba.com "Every thing has its own flow"

1 0

Building VM on windows: lining problem
by phil＠highoctane.be Nov. 19, 2013

Nov. 19, 2013

I've been moving forward with building the VM for Windows from the GitHub sources with MinGW. Now, to get the thing to compile, I had to replace the oft_t things by _oft_t, same for the 64 flavor. So, modifiying two header files, one being mingw.h where I put #define oft_t _oft_t at the end. This did the trick and I now have all plugins/dlls building fine: FT2Plugin.dll libcairo-2.dll libeay32.dll libfreetype-6.dll libfreetype.dll.a libFT2Plugin.dll.a libpixman-1-0.dll libpng-3.dll libSqueakFFIPrims.dll.a libSqueakSSL.dll.a SqueakFFIPrims.dll SqueakSSL.dll ssleay32.dll zlib1.dll are in results/ Also, to get there, one has to create a vmVersionInfo.h file in platforms\Cross\vm with something in the REVISION_STRING #define REVISION_STRING "Pharo VM - Philippe Back from GitHub Sources 20131119" I wonder why this isn't something automagically generated in the process as it seems that the CI build has something. The last step is getting Pharo.exe to link but this doesn't work: Linking C executable /C/MinGW/msys/1.0/home/Philippe/pharo-vm/results/Pharo.exe c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: cannot fin d -lcrtdll collect2.exe: error: ld returned 1 exit status make[2]: *** [C:/MinGW/msys/1.0/home/Philippe/pharo-vm/results/Pharo.exe] Error 1 make[1]: *** [CMakeFiles/Pharo.dir/all] Error 2 make: *** [all] Error 2 Looks like a library path is wrong or else. Idea? Also, there are quite a number of warnings spit out during the compiling process all over the place, more than the Mac VM build I think. e.g. [ 92%] Building C object CMakeFiles/Pharo.dir/C_/MinGW/msys/1.0/home/Philippe/ph aro-vm/platforms/win32/vm/sqWin32Prefs.c.obj In file included from C:/MinGW/msys/1.0/home/Philippe/pharo-vm/platforms/Cross/v m/sq.h:193:0, from c:/MinGW/msys/1.0/home/Philippe/pharo-vm/platforms/win32/v m/sqWin32Prefs.c:20: C:/MinGW/msys/1.0/home/Philippe/pharo-vm/platforms/win32/vm/sqPlatformSpecific.h :52:0: warning: "VM_EXPORT" redefined [enabled by default] # define VM_EXPORT __declspec( dllexport ) ^ In file included from c:/MinGW/msys/1.0/home/Philippe/pharo-vm/platforms/win32/v m/sqWin32Prefs.c:20:0: C:/MinGW/msys/1.0/home/Philippe/pharo-vm/platforms/Cross/vm/sq.h:48:0: note: thi s is the location of the previous definition #define VM_EXPORT ^ [ 93%] Building C object CMakeFiles/Pharo.dir/C_/MinGW/msys/1.0/home/Philippe/ph aro-vm/platforms/win32/vm/sqWin32Utils.c.obj In file included from C:/MinGW/msys/1.0/home/Philippe/pharo-vm/platforms/Cross/v m/sq.h:193:0, from c:/MinGW/msys/1.0/home/Philippe/pharo-vm/platforms/win32/v m/sqWin32Utils.c:14: C:/MinGW/msys/1.0/home/Philippe/pharo-vm/platforms/win32/vm/sqPlatformSpecific.h :52:0: warning: "VM_EXPORT" redefined [enabled by default] # define VM_EXPORT __declspec( dllexport ) ^ In file included from c:/MinGW/msys/1.0/home/Philippe/pharo-vm/platforms/win32/v m/sqWin32Utils.c:14:0: C:/MinGW/msys/1.0/home/Philippe/pharo-vm/platforms/Cross/vm/sq.h:48:0: note: thi s is the location of the previous definition #define VM_EXPORT Phil

1 1

[pharo-project/pharo-core]
by GitHub Nov. 19, 2013

Nov. 19, 2013

Branch: refs/tags/30583 Home: https://github.com/pharo-project/pharo-core

1 0

[pharo-project/pharo-core] dfb2a2: 30583
by GitHub Nov. 19, 2013

Nov. 19, 2013

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: dfb2a225c77d44a402ec8a816641dec7f1d8666c https://github.com/pharo-project/pharo-core/commit/dfb2a225c77d44a402ec8a81… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-11-19 (Tue, 19 Nov 2013) Changed paths: M Kernel.package/Number.class/README.md A Refactoring-Critics.package/RBTempVarOverridesInstVarRule.class/instance/copying/postCopy.st M Refactoring-Critics.package/RBTempVarOverridesInstVarRule.class/instance/initialization/initialize.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script238.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30583.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Core.package/CollectionValueHolder.class/instance/protocol/atWrap_put_.st M Spec-Core.package/DictionaryValueHolder.class/instance/protocol/fillFrom_with_.st Log Message: ----------- 30583 12195 CollectionValueHolder >> #atWrap:put: has variable name clashes https://pharo.fogbugz.com/f/cases/12195 12194 RBTempVarOverridesInstVarRule missed #postCopy https://pharo.fogbugz.com/f/cases/12194 12196 Minor mistakes in class comment of Number class https://pharo.fogbugz.com/f/cases/12196 http://files.pharo.org/image/30/30583.zip

1 0

For testing: fix for Issue 12193 "temp variable mapping wrong in the debugger"
by Marcus Denker Nov. 19, 2013

Nov. 19, 2013

â¦ that is possible fix. Or fix of one of the problemsâ¦ In the old bytecode, block creation was done with a message send, so #stepToSendOrReturn never run across a block creation boundary. Now, with the block creation bytecode, if you step, it will run until the first send of access in the block, executing the block setup code, which I think is what causes the bug. 1) added #willCreateBlock that checks if the next bytecode is a block creation bc 2) #stepToSendOrReturn now checks for blocks, too. 12193 temp variable mapping wrong in the debugger https://pharo.fogbugz.com/f/cases/12193

1 0

VM on Windows with MingGW - Error with off_64 [solved]
by phil＠highoctane.be Nov. 19, 2013

Nov. 19, 2013

This building problem seems to be caused by a MinGW bug: http://sourceforge.net/p/mingw/bugs/2024/ So, one solution for the time being is to edit io.h of the MinGW distribution. Replace (line 301 and 302): 1. __CRT_INLINE off64_t lseek64 (int, off64_t, int); 2. __CRT_INLINE off64_t lseek64 (int fd, off64_t offset, int whence) with 1. __CRT_INLINE _off64_t lseek64 (int, _off64_t, int); 2. __CRT_INLINE _off64_t lseek64 (int fd, _off64_t offset, int whence) i.e. replace all occurences of *off64_t* with *_off64_t* Then I found this: http://stackoverflow.com/questions/19666666/mingw-g-does-not-recognize-off-… I don't know where to change the g++ thing with CMake. Anyone knowing? Phil

1 0

Building the VM on Windows - weird git message
by phil＠highoctane.be Nov. 18, 2013

Nov. 18, 2013

I am trying to get the VM to build on Windows 8, following the procedure outlined on https://github.com/pharo-project/pharo-vm When doing a git clone, I do get the following: Philippe@gravitation7 ~ $ git clone --depth=1 https://github.com/pharo-project/pharo-vm.git Cloning into 'pharo-vm'... remote: Counting objects: 17493, done. remote: Compressing objects: 100% (12363/12363), done. remote: Total 17493 (delta 4271), reused 17137 (delta 4143) Receiving objects: 100% (17493/17493), 19.28 MiB | 1.88 MiB/s, done. Resolving deltas: 100% (4271/4271), done. Checking connectivity... done *error: unable to create file mc/VMMaker-oscog.package/GeniePlugin.class/instance* */primSameClassAbsoluteStrokeDistanceMyPoints.otherPoints.myVectors.otherVectors.* *mySquaredLengths.otherSquaredLengths.myAngles.otherAngles.maxSizeAndReferenceFla* *g.rowBase.rowInsertRemove.rowInsertRemoveCount..st (Filename too long)* Checking out files: 100% (17525/17525), done. fatal: unable to checkout working tree warning: Clone succeeded, but checkout failed. You can inspect what was checked out with 'git status' and retry the checkout with 'git checkout -f HEAD' Pretty weird error I'd say. Anyone knowing what this is related to? Phil

2 1

long double & NativeBoost
by phil＠highoctane.be Nov. 18, 2013

Nov. 18, 2013

How can I use long doubles with NativeBoost? For improved calculations, as we do not have such things in the image it seems. (I may be 100% wrong here but it seems our floats are 32 bit). TIA Phil

1 0

Re: [Pharo-dev] SuperCollider on Pharo [was: realtime]
by Paul Davidowitz Nov. 18, 2013

Nov. 18, 2013

The main processing is done on the backend, the model. Javascript/HTML5 is the audio 'view'. >Good to hear you got the results you wanted. > >So you abandoned pharo as an idea ? >On Mon, Nov 18, 2013 at 7:00 PM, Paul Davidowitz <pdavidow(a)fastmail.fm>wrote: > >> I would just like to mention that I have achieved great audio results >> directly in the (Chrome) browser using HTML5 audio and javascript. >> >> - Paul >>

1 0

Re: [Pharo-dev] SuperCollider on Pharo [was: realtime]
by Paul Davidowitz Nov. 18, 2013

Nov. 18, 2013

I would just like to mention that I have achieved great audio results directly in the (Chrome) browser using HTML5 audio and javascript. - Paul

2 1