- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Packages remodularization

by StÃ©phane Ducasse

Thanks :) > It is very simple to change class categories however I suppose that to > fight with MC and automatic updates will be a hell. Yes but we should succeed :) but yes if will be probably difficult. > So maybe we should > prepare a simple reorganization script, upload new packages, prepare > prebuild image and break update process here as several times in the > past. The next step will be some reorganization of method categories. Stef > Hi, > > I collected information about classes present in the Pharo-Kernel and > the result is the set of packages that are essential for Pharo. This > is a list of this packages with some small reorganizations proposals. > If the packages will be reorganized, the shrinking process will be > start to be package-oriented and Pharo more modular. > > Announcements without Announcements-View category > > Collections without KedamaFloatArrayAbstract, Transcripter > > Compiler > > Exceptions (Exceptions-Extensions category is empty) > > Files > > Graphics: > - Graphics-Display Objects without CornerRounder, DisplayText > - Graphics-Primitives without Pen, PenPointRecorder > - Graphics-Text (only class TextStyle) > - Graphics-Transformations without MorphicTransform > > Kernel > > some classes should be moved to Exceptions package: > - BlockCannotReturn > - ArithmeticError > - FloatingPointException > > some classes should be moved to a new UIManager package > - ProvideAnswerNotification > - ProgressInitiationException > - ProgressNotification > > Multilingual: > - Multilingual-Encodings > - Multilingual-ImmPlugin > - Multilingual-Languages > - Multilingual-TextConversion > > some classes should be moved to a new Base64 package > - MimeConverter > - Base64MimeConverter > > ST80-Kernel-Remnants (ValueHolder, StringHolder) should have own > package or to be part of the Kernel package > > System: > - System-Change Notification (all classes) > - System-Changes (all classes) > - System-Clipboard (all classes) > - System-Download (only AbstractLauncher) > - System-FileRegistry (all classes) > - System-Finalization (all classes) > - System-Localization (all classes, at least for now ;-) > - System-Object Events (all classes) > - System-Object Storage (all classes) > - System-Platforms (all classes) > - System-Pools (all classes) > - System-Support without AbstractSoundSystem, DummySoundSystem, > FontSubstitutionDuringLoading, Imports, MczInstaller, RealEstateAgent, > SARInstaller, SoundSettings > - System-Tools only classes MethodReference, BreakPoint, BreakpointManager > > (better modularization of System package is welcome) > > ToolBuilder-Kernel: > - UIManager class should be in standalone package, maybe together > with DummyUIManager (currently not present in Pharo) > > Tools: > - Tools-Changes > - keep: ChangeSetCategory, ChangeSetCategoryWithParameters, > ElementCategory, ObjectWithDocumentation, StaticChangeSetCategory > - remove: ChangeList, ChangeListForProjects, ChangeSetBrowser, > ChangeSorter, ClassCommentVersionsBrowser, DualChangeSorter, > VersionsBrowser > - Tools-Debugger > - keep: DebuggerMethodMap, DebuggerMethodMapForBlueBookMethods, > DebuggerMethodMapForClosureCompiledMethods, PointerFinder > - remove: ContextVariablesInspector,. Debugger, MessageTally, > PreDebugWindow, SyntaxError, TimeProfileBrowser > - class ThreadSafeTranscript (could be moved to Collections-Streams, > this class is a little bit Morphic dependent but this will be fixed) > > Traits > > > It is very simple to change class categories however I suppose that to > fight with MC and automatic updates will be a hell. So maybe we should > prepare a simple reorganization script, upload new packages, prepare > prebuild image and break update process here as several times in the > past. The next step will be some reorganization of method categories. > > Cheers, > -- Pavel > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 2, 2010

Re: [Pharo-project] Q: is there a way to get the classes referenced by a class?

by Mariano Martinez Peck

I found that very useful....I need it too, O2 too....shouldn't we add this to Class protocol ? On Tue, Mar 2, 2010 at 10:50 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Look the DependencyWalker of hernan morales. Look his class side method > extensions to Behavior. There is all you need > > cheers > > mariano > > > On Mon, Mar 1, 2010 at 9:28 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > >> Thank you, Miguel and Alexandre... I'm looking into it :) >> >> Cheers, >> Esteban >> >> On 2010-03-01 16:59:23 -0300, Alexandre Bergel >> <alexandre(a)bergel.eu> said: >> >> > >> > >> > Hi Esteban, >> > >> > I made a small extension of O2 that shows external dependencies. It is >> > not perfect, but I find it useful. I attached some screenshots. >> > The second screenshot shows that the package Network-Kernel has 6 >> > methods that references the package ToolBuilder-Kernel. >> > Right clicking on the mondrian node opens a menu that enable you to >> > browse the method. I use this tool to make sure I do not have any >> > unwanted dependencies. >> > >> > It works on PharoCore 1.1. To load it: >> > >> > #('DependencyView') >> > do: [:t | >> > | name | >> > name := 'ConfigurationOf', t. >> > Gofer new >> > squeaksource: 'MetacelloRepository'; >> > package: name; >> > load. >> > ((Smalltalk at: name asSymbol) project perform: #lastVersion) load >> ]. >> > >> > Cheers, >> > Alexandre >> > >> > >> > >> > <image> >> > >> > <image> >> > >> > >> > On 1 Mar 2010, at 15:58, Esteban Lorenzano wrote: >> > >> >> Hi, >> >> I'm trying to get a "dependency map" of a certain project (playing >> >> with >> >> pavel's kernel image, I'm trying to figure out how to feed it with all >> >> needed dependences). >> >> What I'm doing now is very inneficient (usign #allCallsOn and >> >> reversing >> >> the search), and I'm sure there should be something better... >> >> >> >> Thanks, >> >> Esteban >> >> >> >> >> >> >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> Pharo-project(a)lists.gforge.inria.fr >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

March 2, 2010

Re: [Pharo-project] Q: is there a way to get the classes referenced by a class?

by Mariano Martinez Peck

Look the DependencyWalker of hernan morales. Look his class side method extensions to Behavior. There is all you need cheers mariano On Mon, Mar 1, 2010 at 9:28 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > Thank you, Miguel and Alexandre... I'm looking into it :) > > Cheers, > Esteban > > On 2010-03-01 16:59:23 -0300, Alexandre Bergel > <alexandre(a)bergel.eu> said: > > > > > > > Hi Esteban, > > > > I made a small extension of O2 that shows external dependencies. It is > > not perfect, but I find it useful. I attached some screenshots. > > The second screenshot shows that the package Network-Kernel has 6 > > methods that references the package ToolBuilder-Kernel. > > Right clicking on the mondrian node opens a menu that enable you to > > browse the method. I use this tool to make sure I do not have any > > unwanted dependencies. > > > > It works on PharoCore 1.1. To load it: > > > > #('DependencyView') > > do: [:t | > > | name | > > name := 'ConfigurationOf', t. > > Gofer new > > squeaksource: 'MetacelloRepository'; > > package: name; > > load. > > ((Smalltalk at: name asSymbol) project perform: #lastVersion) load > ]. > > > > Cheers, > > Alexandre > > > > > > > > <image> > > > > <image> > > > > > > On 1 Mar 2010, at 15:58, Esteban Lorenzano wrote: > > > >> Hi, > >> I'm trying to get a "dependency map" of a certain project (playing > >> with > >> pavel's kernel image, I'm trying to figure out how to feed it with all > >> needed dependences). > >> What I'm doing now is very inneficient (usign #allCallsOn and > >> reversing > >> the search), and I'm sure there should be something better... > >> > >> Thanks, > >> Esteban > >> > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 2, 2010

[Pharo-project] Packages remodularization

by Pavel Krivanek

Hi, I collected information about classes present in the Pharo-Kernel and the result is the set of packages that are essential for Pharo. This is a list of this packages with some small reorganizations proposals. If the packages will be reorganized, the shrinking process will be start to be package-oriented and Pharo more modular. Announcements without Announcements-View category Collections without KedamaFloatArrayAbstract, Transcripter Compiler Exceptions (Exceptions-Extensions category is empty) Files Graphics: - Graphics-Display Objects without CornerRounder, DisplayText - Graphics-Primitives without Pen, PenPointRecorder - Graphics-Text (only class TextStyle) - Graphics-Transformations without MorphicTransform Kernel some classes should be moved to Exceptions package: - BlockCannotReturn - ArithmeticError - FloatingPointException some classes should be moved to a new UIManager package - ProvideAnswerNotification - ProgressInitiationException - ProgressNotification Multilingual: - Multilingual-Encodings - Multilingual-ImmPlugin - Multilingual-Languages - Multilingual-TextConversion some classes should be moved to a new Base64 package - MimeConverter - Base64MimeConverter ST80-Kernel-Remnants (ValueHolder, StringHolder) should have own package or to be part of the Kernel package System: - System-Change Notification (all classes) - System-Changes (all classes) - System-Clipboard (all classes) - System-Download (only AbstractLauncher) - System-FileRegistry (all classes) - System-Finalization (all classes) - System-Localization (all classes, at least for now ;-) - System-Object Events (all classes) - System-Object Storage (all classes) - System-Platforms (all classes) - System-Pools (all classes) - System-Support without AbstractSoundSystem, DummySoundSystem, FontSubstitutionDuringLoading, Imports, MczInstaller, RealEstateAgent, SARInstaller, SoundSettings - System-Tools only classes MethodReference, BreakPoint, BreakpointManager (better modularization of System package is welcome) ToolBuilder-Kernel: - UIManager class should be in standalone package, maybe together with DummyUIManager (currently not present in Pharo) Tools: - Tools-Changes - keep: ChangeSetCategory, ChangeSetCategoryWithParameters, ElementCategory, ObjectWithDocumentation, StaticChangeSetCategory - remove: ChangeList, ChangeListForProjects, ChangeSetBrowser, ChangeSorter, ClassCommentVersionsBrowser, DualChangeSorter, VersionsBrowser - Tools-Debugger - keep: DebuggerMethodMap, DebuggerMethodMapForBlueBookMethods, DebuggerMethodMapForClosureCompiledMethods, PointerFinder - remove: ContextVariablesInspector,. Debugger, MessageTally, PreDebugWindow, SyntaxError, TimeProfileBrowser - class ThreadSafeTranscript (could be moved to Collections-Streams, this class is a little bit Morphic dependent but this will be fixed) Traits It is very simple to change class categories however I suppose that to fight with MC and automatic updates will be a hell. So maybe we should prepare a simple reorganization script, upload new packages, prepare prebuild image and break update process here as several times in the past. The next step will be some reorganization of method categories. Cheers, -- Pavel

March 2, 2010

Re: [Pharo-project] O2 now loads in Pharo Core 1.1

by Laval Jannik

Thank you Alex, I test it today :) On Mar 1, 2010, at 22:09 , Alexandre Bergel wrote: > I just wanted to announce this :-) > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project --- Jannik Laval

March 2, 2010

Re: [Pharo-project] Scamper revival

by Eagle Offshore

Squeak - Pharo - same thing. I didn't say it would wipe out Smalltalk's place in the world - I said it will fulfill its mission - which is one more level of marginalization. At this point, it is easier to write a portable desktop app in a webkit based browser than it is to write one in Pharo. On Mar 1, 2010, at 4:20 AM, Schwab,Wilhelm K wrote: > First, I'm not using Squeak. Second, this is not the first time I've heard that xyz was going to wipe out Smalltalk's place in the world, and I doubt it will be the last. > > Bill > > > -----Original Message----- > From: Eagle Offshore [mailto:eagleoffshore@mac.com] > Sent: Monday, March 01, 2010 12:09 AM > To: Schwab,Wilhelm K > Subject: Re: [Pharo-project] Scamper revival > > Then what are you doing with Squeak? :-) The browsers support offline development with local databases in HTML 5. This is here, now. They will replace squeak's mission in about another three years. Probably less. > > On Feb 28, 2010, at 12:04 PM, Schwab,Wilhelm K wrote: > >> There is the further concern about the browser. It wastes screen space (which is at a premium) and adds weight and distracting functionality. There is something to be said for the a fat client app that does what it needs to do and nothing else. >> >> >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of >> Eagle Offshore >> Sent: Sunday, February 28, 2010 2:23 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Scamper revival >> >> I wouldn't be so sure. >> >> http://html5demos.com/ >> http://jqtouch.com/ >> >> On Feb 27, 2010, at 4:41 PM, Schwab,Wilhelm K wrote: >> >>> there is no way in hell that HTML+CSS+JavaScript is going to keep up >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 2, 2010

Re: [Pharo-project] Polymorph fixes

by Gary Chambers

Yes, Hilaire is doing a theme to match the XO UI specs... some good will come from this for Polymorph generally, in terms of extending the "Widget set"... date pickers etc... On Mon, 2010-03-01 at 23:20 +0100, Richard Durr wrote: > What's the Sugar theme? For the XO-Laptop? > > On Mon, Mar 1, 2010 at 8:34 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > > Thanks. > > I will give a try but may be we have a bug in scriptLoader :) > > > > Stef > > On Mar 1, 2010, at 6:52 PM, Gary Chambers wrote: > > > >> A few fixes on SqueakSource. > >> > >> Polymorph-Widgets-gvc.24 > >> Polymorph-Tools-Diff-gvc.24 > >> > >> Notably: > >> > >> Table layout of submorphs with #shrinkWrap attributes. > >> Themeing of menu item text colours to help Hilaire in his Sugar theme efforts. ThemeSettings integration left for another time... > >> Wrong "sides" for "compare to current" when using diff tools in change sets (versions browser etc.). > >> Prevention of window dragging from submorphs promoted from StandardWindow to SystemWindow (deals with oddities when click-dragging from submorphs... offset would be wrong and window "jumps"). > >> Wrong colours for faded background windows in Watery themes. > >> Fix colours in W2K theme (requires class-side reinitialisation of defaultSettings. Do "UIThemeW2K defaultSettings: nil" before changing theme). > >> Toolbars now Panel-based to adapt to pane colour. > >> DockingBar based menus now deal with mouseFocus correctly. > >> > >> > >> Regards, Gary > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 2, 2010

Re: [Pharo-project] Trying to build alien plugin in linux

by John M McIntosh

It would be missing, propose a change set. I would think people usually don't use VMMaker images as their daily work image. So take image, load vmaker, load vmaker stuff for alien, make alien plugin. got to my work image that doesn't have vmmaker in it, load alien support stuf, you don't need the alien-vmmaker-support btw. run tests. On 2010-03-01, at 3:36 PM, Javier PimÃ¡s wrote: > Hi, I'm still trying to advance with this. Don't know what caused the ObjectMemory classPools but it seems to be away now, maybe I did some mistake last time. > > The thing is that now I have in ObjectMemory classPools all the original ones plus 4 new elements, which I think were added with this Alien-VMMaker-Support override: > > ObjectMemory>>#initialize > initialize > #( #ClassAlien #ClassUnsafeAlien #InvokeCallbackSelector #SelectorAttemptToAssign) > do: [:c | > [ObjectMemory addClassVarName: c] ifError: []]. > > the thing is that it never assigns them any value, so my theory is that there's some code missing? Then in Interpreter it happens something quite similar. Interpreter>>#initialize does this: > > ... > > #(#PrimErrBadArgument #PrimErrBadIndex #PrimErrBadNumArgs #PrimErrBadReceiver #PrimErrGenericFailure #PrimErrInappropriate #PrimErrNoCMemory #PrimErrNoMemory #PrimErrNoModification #PrimErrNotFound #PrimErrTableIndex #PrimErrUnsupported #PrimNoErr ) > do: [:c | > [Interpreter addClassVarName: c] ifError: []]. > > #(#primFailCode) > do: [:i | [Interpreter addInstVarName: i] ifError: []]. > > ... > > but then never calls initializePrimitiveErrorCodes, which would set the vars to a meaningfull value. > > > In conclusion, the question would be, where is this missing initialization code? > > Hope you can help, thanks! > > Javier. > > On Tue, Feb 23, 2010 at 4:39 PM, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: > > > On Tue, Feb 23, 2010 at 12:19 AM, John M McIntosh <johnmci(a)smalltalkconsulting.com> wrote: > > On 2010-02-22, at 6:48 PM, Javier PimÃ¡s wrote: > >> Nice!!!!!!!! It's compiling now. Now, I loaded tests, and here are the results: >> >> 37 run, 17 passed, 0 failures, 20 errors. >> >> TestCallingSequenceChar10Long2 >> TestCallingSequenceChar2LongLong2 >> TestCallingSequenceChar8Long2 >> TestCallingSequenceChar9Long2 >> TestCallingSequenceCharLongLong2 >> TestCallingSequenceChars >> TestCallingSequenceDoubles14 >> TestCallingSequenceDoubles2 >> TestCallingSequenceFloats13 >> TestCallingSequenceFloats14 >> TestCallingSequenceFloats2 >> TestCallingSequenceFloats2WithInteger >> TestCallingSequenceFloats2WithInteger2 >> TestCallingSequenceFloats7 >> TestCallingSequenceInt >> TestCallingSequenceInt8 >> TestCallingSequenceIntWithFloatArgs >> TestCallingSequenceLongLong2 >> TestCallingSequenceShort >> TestCallingSequenceString > > Oh look SUnits, great stuff (*cough* well I wrote most of them). > > > Cool, this is really really useful (although I sometimes find wrting tests boring ;) ). >> >> >> It is failing in places where it does primLoadLibrary: 'IA32ABI'. Why should it try to load itself, if it's compiled as an internal plugin? I compiled it as external too but didn't work either. > > Well it compiled, but that doesn't mean it works. In fact the error means the plugin code is never loaded, or is callable. > Now one thing to consider is that the plugin load fails, because it can't find it. (external usage). > Or because (internal and external plugin) the VM Version and the plugin version don't match. > > Look for your definition of > #define VM_PROXY_MINOR 8 > > It should be 8 or higher for compiling BOTH the VM and the Plugin. > Since the sqVirtualMachine.h is in the IA32ABI folder maybe there is mass confusion about which header is being used? > > If for example your VM say it's a VM_PROXY_MINOR of 7, then it won't work with a plugin compiled with VM_PROXY_MINOR = 8. > It silently fails... Well actually it gives the primLoadLibrary failure, but good luck in guessing why... > > Well, I just overwrote sqVirtualMachine.c/h in Cross/vm, shouldn't have I? It wouldn't compile if I didn't and its sets it to 8. Is it defined in any other place? > > > >> >> Other question, can classic FFI and Alien live nicely together (I mean have x plugin use classic FFI while y uses Alien)? >> > > yes. > >> One more: should I use IA32ABIPlugin or IA32ABIPluginAttic? You can't have both in, right? > > One is a subclass of the other. I use the IA32ABIPluginAttic one. > > Ok, what is the difference between them? a performance issue? everything works the same I choose one or the other? > > >> >> Syntax highligthing is broken for Alien primitive methods like these: >> >> <primitive: 'primUnsignedShortAtPut' error: errorCode module: 'IA32ABI'> >> >> Lastly, as I said when I loaded Alien Core the first time, I got this error while loading it: >> >> Alien class>>#ensureInSpecialObjectsArray: "Index probably wrong". >> >> What should I do about that? ignore it? > > Well it seems to be related to > > ((Smalltalk includesKey: #ObjectMemory) > and: [((Smalltalk at: #ObjectMemory) classPool at: #ClassAlien ifAbsent: []) ~~ (index - 1)]) ifTrue: > [self error: 'index probably wrong']. > > Usually people don't have ObjectMemory loaded in their image, and I"m not sure what it is check for. > Why don't you try it in a regular Pharo image versus your VMMaker image. > > > In Pharo 1.0RC2 without any change, ObjectMemory doesn't exist. When I load VMMaker it's downloaded from monticello, but obviously, #ClassAlien isn't defined inside > > (Smalltalk at: #ObjectMemory) classPool > > Interestingly, after load alien, #ClassAlien gets added as a key, but all values of (Smalltalk at: #ObjectMemory) classPool are set to nil, like this: > > (Smalltalk at: #ObjectMemory) classPool inspect: > > - size : 119 > [#AllButHashBits] : nil > [#AllButMarkBit] : nil > [#AllButMarkBitAndTypeMask] : nil > [#AllButRootBit] : nil > [#AllButTypeMask] : nil > ... > [#ClassAlien] : nil > ... > > > Any ideas? > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

March 2, 2010

Re: [Pharo-project] Trying to build alien plugin in linux

by Javier PimÃ¡s

Hi, I'm still trying to advance with this. Don't know what caused the ObjectMemory classPools but it seems to be away now, maybe I did some mistake last time. The thing is that now I have in ObjectMemory classPools all the original ones plus 4 new elements, which I think were added with this Alien-VMMaker-Support override: ObjectMemory>>#initialize initialize #( #ClassAlien #ClassUnsafeAlien #InvokeCallbackSelector #SelectorAttemptToAssign) do: [:c | [ObjectMemory addClassVarName: c] ifError: []]. the thing is that it never assigns them any value, so my theory is that there's some code missing? Then in Interpreter it happens something quite similar. Interpreter>>#initialize does this: ... #(#PrimErrBadArgument #PrimErrBadIndex #PrimErrBadNumArgs #PrimErrBadReceiver #PrimErrGenericFailure #PrimErrInappropriate #PrimErrNoCMemory #PrimErrNoMemory #PrimErrNoModification #PrimErrNotFound #PrimErrTableIndex #PrimErrUnsupported #PrimNoErr ) do: [:c | [Interpreter addClassVarName: c] ifError: []]. #(#primFailCode) do: [:i | [Interpreter addInstVarName: i] ifError: []]. ... but then never calls initializePrimitiveErrorCodes, which would set the vars to a meaningfull value. In conclusion, the question would be, where is this missing initialization code? Hope you can help, thanks! Javier. On Tue, Feb 23, 2010 at 4:39 PM, Javier PimÃ¡s <elpochodelagente(a)gmail.com>wrote: > > > On Tue, Feb 23, 2010 at 12:19 AM, John M McIntosh < > johnmci(a)smalltalkconsulting.com> wrote: > >> >> On 2010-02-22, at 6:48 PM, Javier PimÃ¡s wrote: >> >> Nice!!!!!!!! It's compiling now. Now, I loaded tests, and here are the >> results: >> >> 37 run, 17 passed, 0 failures, 20 errors. >> >> TestCallingSequenceChar10Long2 >> TestCallingSequenceChar2LongLong2 >> TestCallingSequenceChar8Long2 >> TestCallingSequenceChar9Long2 >> TestCallingSequenceCharLongLong2 >> TestCallingSequenceChars >> TestCallingSequenceDoubles14 >> TestCallingSequenceDoubles2 >> TestCallingSequenceFloats13 >> TestCallingSequenceFloats14 >> TestCallingSequenceFloats2 >> TestCallingSequenceFloats2WithInteger >> TestCallingSequenceFloats2WithInteger2 >> TestCallingSequenceFloats7 >> TestCallingSequenceInt >> TestCallingSequenceInt8 >> TestCallingSequenceIntWithFloatArgs >> TestCallingSequenceLongLong2 >> TestCallingSequenceShort >> TestCallingSequenceString >> >> >> Oh look SUnits, great stuff (*cough* well I wrote most of them). >> >> > Cool, this is really really useful (although I sometimes find wrting tests > boring ;) ). > >> >> >> It is failing in places where it does primLoadLibrary: 'IA32ABI'. Why >> should it try to load itself, if it's compiled as an internal plugin? I >> compiled it as external too but didn't work either. >> >> >> Well it compiled, but that doesn't mean it works. In fact the error means >> the plugin code is never loaded, or is callable. >> Now one thing to consider is that the plugin load fails, because it can't >> find it. (external usage). >> Or because (internal and external plugin) the VM Version and the plugin >> version don't match. >> >> Look for your definition of >> #define VM_PROXY_MINOR 8 >> >> It should be 8 or higher for compiling BOTH the VM and the Plugin. >> Since the sqVirtualMachine.h is in the IA32ABI folder maybe there is mass >> confusion about which header is being used? >> >> If for example your VM say it's a VM_PROXY_MINOR of 7, then it won't work >> with a plugin compiled with VM_PROXY_MINOR = 8. >> It silently fails... Well actually it gives the primLoadLibrary failure, >> but good luck in guessing why... >> > > Well, I just overwrote sqVirtualMachine.c/h in Cross/vm, shouldn't have I? > It wouldn't compile if I didn't and its sets it to 8. Is it defined in any > other place? > > >> >> >> Other question, can classic FFI and Alien live nicely together (I mean >> have x plugin use classic FFI while y uses Alien)? >> >> >> yes. >> >> One more: should I use IA32ABIPlugin or IA32ABIPluginAttic? You can't have >> both in, right? >> >> >> One is a subclass of the other. I use the IA32ABIPluginAttic one. >> > > Ok, what is the difference between them? a performance issue? everything > works the same I choose one or the other? > > >> >> >> Syntax highligthing is broken for Alien primitive methods like these: >> >> <primitive: 'primUnsignedShortAtPut' error: errorCode module: 'IA32ABI'> >> >> Lastly, as I said when I loaded Alien Core the first time, I got this >> error while loading it: >> >> Alien class>>#ensureInSpecialObjectsArray: "Index probably wrong". >> >> What should I do about that? ignore it? >> >> >> Well it seems to be related to >> >> ((Smalltalk includesKey: #ObjectMemory) >> and: [((Smalltalk at: #ObjectMemory) classPool at: #ClassAlien ifAbsent: >> []) ~~ (index - 1)]) ifTrue: >> [self error: 'index probably wrong']. >> >> Usually people don't have ObjectMemory loaded in their image, and I"m not >> sure what it is check for. >> Why don't you try it in a regular Pharo image versus your VMMaker image. >> >> > In Pharo 1.0RC2 without any change, ObjectMemory doesn't exist. When I load > VMMaker it's downloaded from monticello, but obviously, #ClassAlien isn't > defined inside > > (Smalltalk at: #ObjectMemory) classPool > > Interestingly, after load alien, #ClassAlien gets added as a key, but all > values of (Smalltalk at: #ObjectMemory) classPool are set to nil, like this: > > (Smalltalk at: #ObjectMemory) classPool inspect: > > - size : 119 > [#AllButHashBits] : nil > [#AllButMarkBit] : nil > [#AllButMarkBitAndTypeMask] : nil > [#AllButRootBit] : nil > [#AllButTypeMask] : nil > ... > [#ClassAlien] : nil > ... > > > Any ideas? > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > -- Javier PimÃ¡s Ciudad de Buenos Aires

March 1, 2010

Re: [Pharo-project] Polymorph fixes

by Richard Durr

What's the Sugar theme? For the XO-Laptop? On Mon, Mar 1, 2010 at 8:34 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Thanks. > I will give a try but may be we have a bug in scriptLoader :) > > Stef > On Mar 1, 2010, at 6:52 PM, Gary Chambers wrote: > >> A few fixes on SqueakSource. >> >> Polymorph-Widgets-gvc.24 >> Polymorph-Tools-Diff-gvc.24 >> >> Notably: >> >> Table layout of submorphs with #shrinkWrap attributes. >> Themeing of menu item text colours to help Hilaire in his Sugar theme efforts. ThemeSettings integration left for another time... >> Wrong "sides" for "compare to current" when using diff tools in change sets (versions browser etc.). >> Prevention of window dragging from submorphs promoted from StandardWindow to SystemWindow (deals with oddities when click-dragging from submorphs... offset would be wrong and window "jumps"). >> Wrong colours for faded background windows in Watery themes. >> Fix colours in W2K theme (requires class-side reinitialisation of defaultSettings. Do "UIThemeW2K defaultSettings: nil" before changing theme). >> Toolbars now Panel-based to adapt to pane colour. >> DockingBar based menus now deal with mouseFocus correctly. >> >> >> Regards, Gary >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 1, 2010