November 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-bugtracker] FogBugz (Case [Issue]9) _Inbox - Back In Town

by Camillo Bruni

I presume one of the FogBugz API test cases does this. Though not sure. I currently don't have time to look into it. Sources: http://smalltalkhub.com/#!/~Pharo/ci On 2013-11-19, at 13:31, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Among the many messages sent automatically by our magic systems, this one strikes me as useless. It basically says that the monkey is doing something, without being specific: no issue number, nothing. > > Begin forwarded message: > >> From: "Pharo Issue Tracker" <do-not-reply(a)pharo.fogbugz.com> >> Subject: [Pharo-bugtracker] FogBugz (Case [Issue]9) _Inbox - Back In Town >> Date: 19 Nov 2013 13:28:23 GMT+1 >> To: "pharo-bugtracker(a)lists.gforge.inria.fr" <pharo-bugtracker(a)lists.gforge.inria.fr> >> >> A FogBugz case was edited by Ulysse The Galactic Monkey From Outer Space. >> >> Case ID: 9 >> Title: Back In Town >> Status: Closed (Invalid) >> Category: Bug >> Project: _Inbox >> Area: Not Spam >> Priority: 3 - Must Fix >> Milestone: Undecided >> Assigned To: CLOSED >> >> URL: https://pharo.fogbugz.com/f/cases/9 >> >> Communicating from Pharo >> >> >> You are subscribed to this case. If you do not want to receive automatic notifications in the future, unsubscribe (https://pharo.fogbugz.com/default.asp?pre=preUnsubscribe&pg=pgEditBug&comma…) from this case. >> >> _______________________________________________ >> Pharo-bugtracker mailing list >> Pharo-bugtracker(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker > >

Nov. 19, 2013

Fwd: [Pharo-bugtracker] FogBugz (Case [Issue]9) _Inbox - Back In Town

by Sven Van Caekenberghe

Among the many messages sent automatically by our magic systems, this one strikes me as useless. It basically says that the monkey is doing something, without being specific: no issue number, nothing. Begin forwarded message: > From: "Pharo Issue Tracker" <do-not-reply(a)pharo.fogbugz.com> > Subject: [Pharo-bugtracker] FogBugz (Case [Issue]9) _Inbox - Back In Town > Date: 19 Nov 2013 13:28:23 GMT+1 > To: "pharo-bugtracker(a)lists.gforge.inria.fr" <pharo-bugtracker(a)lists.gforge.inria.fr> > > A FogBugz case was edited by Ulysse The Galactic Monkey From Outer Space. > > Case ID: 9 > Title: Back In Town > Status: Closed (Invalid) > Category: Bug > Project: _Inbox > Area: Not Spam > Priority: 3 - Must Fix > Milestone: Undecided > Assigned To: CLOSED > > URL: https://pharo.fogbugz.com/f/cases/9 > > Communicating from Pharo > > > You are subscribed to this case. If you do not want to receive automatic notifications in the future, unsubscribe (https://pharo.fogbugz.com/default.asp?pre=preUnsubscribe&pg=pgEditBug&comma…) from this case. > > _______________________________________________ > Pharo-bugtracker mailing list > Pharo-bugtracker(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Nov. 19, 2013

Re: [Pharo-dev] [Moose-dev] I'm not getting it

by Tudor Girba

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"

Nov. 19, 2013

Re: [Pharo-dev] Building VM on windows: lining problem

by phil＠highoctane.be

I found why the vmVersionInfo.h isn't there... build.sh contains: #!bash if [ ! -e vmVersionInfo.h ]; then ../codegen-scripts/extract-commit-info.sh fi cmake -G "MSYS Makefiles" . make and ../codegen-scripts/extract-commit-info.sh is nowhere to be found from the git clone... It lives in scripts/ Phil On Tue, Nov 19, 2013 at 11:01 AM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > 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 >

Nov. 19, 2013

Building VM on windows: lining problem

by phil＠highoctane.be

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

Nov. 19, 2013

[pharo-project/pharo-core]

by GitHub

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

Nov. 19, 2013

[pharo-project/pharo-core] dfb2a2: 30583

by GitHub

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

Nov. 19, 2013

For testing: fix for Issue 12193 "temp variable mapping wrong in the debugger"

by Marcus Denker

â¦ 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

Nov. 19, 2013

VM on Windows with MingGW - Error with off_64 [solved]

by phil＠highoctane.be

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

Nov. 19, 2013

Re: [Pharo-dev] WhatsUp from: 2013-11-18 until: 2013-11-30

by HernÃ¡n Morales Durand

El 18/11/2013 3:00, seaside(a)rmod.lille.inria.fr escribiÃ³: > Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! > > ### Here's what I've been up to since the last WhatsUp: > > - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS -Make it work GraphViz under Pharo 2.0 in a new StHub repository -Patched Shape package and dependencies for proper loading of ESRI .Shp files. -Added tests, translations and lots of refactorings in the Application Security framework, based in the Yoder 1997's paper. -Testing basic security for an Iliad web site soon to be released. -Evaluating the best alternative to work with geographical maps for representing populations genetics studies. > > ### What's next, until 2013-11-30 (*): > > - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION > - Finalize the tests and check points for the App.Security - Finalize and release the web site in our server. HernÃ¡n

Nov. 19, 2013