October 2011 - Pharo-users - lists.pharo.org

Re: [Pharo-users] [pharo-users] Can't Load Magma in Pharo 1.3

by Ankur Sethi

Hi, On Mon, Oct 24, 2011 at 9:59 PM, Mariano Martinez Peck > > Yes. Go to ThisOSProcess class >> initialize > and replace the addToStartUpList:after:Â by a simple addToStartUpList: I actually loaded the newest version of OSProcess before loading Magma in a fresh image. That works great. Now I'm noticing something else: loading Magma works, but as soon as I load Seaside, I lose all syntax highlighting in the System Browser! I mentioned this issue in my original query, but I assumed Magma was causing it. Turns out it wasn't Magma after all, it was Seaside. Syntax highlighting still works in the workspace. It's only the System Browser that's affected. What do I do? -- Ankur Sethi (GeneralMaximus on IRC and elsewhere)

Oct. 24, 2011

Re: [Pharo-users] [pharo-users] Can't Load Magma in Pharo 1.3

by Mariano Martinez Peck

On Mon, Oct 24, 2011 at 6:24 PM, Ankur Sethi <get.me.ankur(a)gmail.com> wrote: > Hi, > > On Mon, Oct 24, 2011 at 8:37 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: > > Hence, > > ConfigurationOfMagma should be updated to use the new version of > OSProcess. > > Is there a way I can fix this manually in my own image? > > Yes. Go to ThisOSProcess class >> initialize and replace the addToStartUpList:after: by a simple addToStartUpList: cheers > -- > Ankur Sethi > (GeneralMaximus on IRC and elsewhere) > > -- Mariano http://marianopeck.wordpress.com

Oct. 24, 2011

Re: [Pharo-users] [pharo-users] Can't Load Magma in Pharo 1.3

by Ankur Sethi

Hi, On Mon, Oct 24, 2011 at 8:37 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hence, > ConfigurationOfMagma should be updated to use the new version of OSProcess. Is there a way I can fix this manually in my own image? -- Ankur Sethi (GeneralMaximus on IRC and elsewhere)

Oct. 24, 2011

Re: [Pharo-users] [pharo-users] Can't Load Magma in Pharo 1.3

by Mariano Martinez Peck

Hi. It looks like OSProcess (a dependency of Magma) is registering a class in the startUp list explicitly before ImageSegment (which was removed). This was already fixed in new version of OSProcess. Hence, ConfigurationOfMagma should be updated to use the new version of OSProcess. Cheers On Mon, Oct 24, 2011 at 4:54 PM, Ankur Sethi <get.me.ankur(a)gmail.com> wrote: > Hi, > > I'm new to Pharo and Smalltalk in general. I'm trying to build a small > blogging application using Pharo and Seaside. I've decided to use > Magma for persistence, but I'm having some issues loading it in Pharo > 1.3. > > I loaded Magma the usual way: > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfMagma'; > load. > > (Smalltalk at:#ConfigurationOfMagma) > project latestVersion > load: 'Server'; > load: 'Client'. > > ... and I was presented with a backtrace. Since didn't know how to get > a full backtrace out of Pharo in plain text, I took a screenshot: > http://imagebin.org/180559 > > I know this is not adequate, but I'm hoping someone can help me get > Pharo to give me information about this issue in a more convenient > format. > > When I told Pharo to abandon loading the package and then re-evaluated > this: > > (Smalltalk at:#ConfigurationOfMagma) > project latestVersion > load: 'Server'; > load: 'Client'. > > ... then everything went just fine. I even tried creating a Magma > repository, which worked. However, some things were totally borked in > my Pharo image. I couldn't get the System Browser to do syntax > highlighting, for one. > > I'm using Pharo1.3 + CogVM 13307 on Mac OS X Lion. > > I hope I made sense. > > Thanks. > > -- > Ankur Sethi > (GeneralMaximus on IRC and elsewhere) > > -- Mariano http://marianopeck.wordpress.com

Oct. 24, 2011

[pharo-users] Can't Load Magma in Pharo 1.3

by Ankur Sethi

Hi, I'm new to Pharo and Smalltalk in general. I'm trying to build a small blogging application using Pharo and Seaside. I've decided to use Magma for persistence, but I'm having some issues loading it in Pharo 1.3. I loaded Magma the usual way: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfMagma'; load. (Smalltalk at:#ConfigurationOfMagma) project latestVersion load: 'Server'; load: 'Client'. ... and I was presented with a backtrace. Since didn't know how to get a full backtrace out of Pharo in plain text, I took a screenshot: http://imagebin.org/180559 I know this is not adequate, but I'm hoping someone can help me get Pharo to give me information about this issue in a more convenient format. When I told Pharo to abandon loading the package and then re-evaluated this: (Smalltalk at:#ConfigurationOfMagma) project latestVersion load: 'Server'; load: 'Client'. ... then everything went just fine. I even tried creating a Magma repository, which worked. However, some things were totally borked in my Pharo image. I couldn't get the System Browser to do syntax highlighting, for one. I'm using Pharo1.3 + CogVM 13307 on Mac OS X Lion. I hope I made sense. Thanks. -- Ankur Sethi (GeneralMaximus on IRC and elsewhere)

Oct. 24, 2011

Re: [Pharo-users] [Pharo-project] Planning a nice pharo conference :)

by eMko

Thank you :) Martin MadÄra -- View this message in context: http://forum.world.st/Planning-a-nice-pharo-conference-tp3902751p3932872.ht… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Oct. 24, 2011

Re: [Pharo-users] How to get temp names of BlockClosure

by Igor Stasenko

On 24 October 2011 12:44, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Oct 24, 2011, at 12:40 PM, Marcus Denker wrote: >> >>> While looking I found >>> >>> [:a :b :c| ] method tempNames Â #('[a' 'b' 'c]') >>> >>> For me there are two errors. >> >> yes, this is wrong. >> >> The real problem is that the CompiledMethod does not store any info about temp names, >> so you need to either go to the source text or (better) AST... and than there is Dan's clever hack >> that can save temp names in the method trailer to allow decompiling without sources, complicating >> the logic in addition. >> > > Ah, and the temp-names embedded in the trailer is used excactly for DoIts... because normally the > #tempNames should always return an empty list. > > It only has meaning when using Dan's embedded temp-names in the trailer hack, which for the whole > image nobody ever uses since years. > yes, i think this is too much effort(s) for displaying a do-it temp names in debugger. As you said, it is possible to embed temps into compiled method, but it is largely unused in system, and used only for doits. Definitely, the way how (often) we using it in our system(s) was not worth spending manhours implementing it. > Â Â Â Â Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > > > -- Best regards, Igor Stasenko.

Oct. 24, 2011

Re: [Pharo-users] How to get temp names of BlockClosure

by Marcus Denker

On Oct 24, 2011, at 12:40 PM, Marcus Denker wrote: > >> While looking I found >> >> [:a :b :c| ] method tempNames #('[a' 'b' 'c]') >> >> For me there are two errors. > > yes, this is wrong. > > The real problem is that the CompiledMethod does not store any info about temp names, > so you need to either go to the source text or (better) AST... and than there is Dan's clever hack > that can save temp names in the method trailer to allow decompiling without sources, complicating > the logic in addition. > Ah, and the temp-names embedded in the trailer is used excactly for DoIts... because normally the #tempNames should always return an empty list. It only has meaning when using Dan's embedded temp-names in the trailer hack, which for the whole image nobody ever uses since years. Marcus -- Marcus Denker -- http://marcusdenker.de

Oct. 24, 2011

Re: [Pharo-users] How to get temp names of BlockClosure

by Marcus Denker

On Oct 17, 2011, at 4:57 PM, Norbert Hartl wrote: > I'm trying to learn how to get temp names from a BlockClosure. Well, I try to be able to treat BlockClosures the same way than CompileMethod when it comes to arguments. I can do > > [:a :b :c| ] asContext tempNames #('a' 'b' 'c') > > but I'm not sure if this is the best to go. Yes, this uses the DebuggerMethodMap and thus should hide the temps that are there just to store the tempVecor. (with the closure design, there are temps that are just implementation artefacts, not temps that where defined). > While looking I found > > [:a :b :c| ] method tempNames #('[a' 'b' 'c]') > > For me there are two errors. yes, this is wrong. The real problem is that the CompiledMethod does not store any info about temp names, so you need to either go to the source text or (better) AST... and than there is Dan's clever hack that can save temp names in the method trailer to allow decompiling without sources, complicating the logic in addition. I always think that all this is an epic mess... but other people like it. Marcus -- Marcus Denker -- http://marcusdenker.de

Oct. 24, 2011

Re: [Pharo-users] GlorpDBX

by Mariano Martinez Peck

On Mon, Oct 24, 2011 at 9:28 AM, Jonathan Kelly <jonkelly(a)fastmail.fm>wrote: > Hi, > > > feeling particularly stupid right now. Been trying to get Glorp DBX > working with Postgresql for the last 2 hours and I'm busted. It took me > about an out just to find out how to load and configure things. ugh. It > took me a while to work out I had to actually install OpenDBX (doh). So > I have downloaded that and added the directory to my PATH. > That's good. > > So I'm trying to run the tests and I get DBXFatalError: FATAL OpenDBX: > Loading backend library failed. I know it's finding OpenDBX, Now, it is not that it is not finding OpenDBX, but PostgreSQL client library > because > when I move the OpenDBX folder, I get a different error - "Error: > External Module Not Found" from apiInitialize (and I can see it's > trying to load libopendbx-1.dll). > > Part of my problem is squeakdbx.org domain expired on 09/27/11 and is > now a godaddy parking page. double ugh. > > We have announced in all possible mailing lists that it was temporaly moved to http://dbxtalk.smallworks.com.ar/squeakdbx Check this links: http://dbxtalk.smallworks.com.ar/Compiling%20and%20installing%20OpenDBX http://dbxtalk.smallworks.com.ar/Installation > Anyone got any ideas? > Install PostgreSQL client library (32 bits) and make sure its lib is findable by windows. Cheers I'm running a fresh 1.3 using CogVM-Win-13307 install on Windows XP. > Jonathan. > > -- Mariano http://marianopeck.wordpress.com

Oct. 24, 2011