January 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Trying to build CogVM in MacOSX 10.7 Lion

by dimitris chloupis

its ok , I am not in any hurry you can take all the time in the world. Thanks for helping me to go that far. You were right downloading that file did not help. But all is ok, I already have a NBCogVm app to play around , trying both CogVM and Nativeboost. I know that there are some things that one cannot Â rush, and I know Pharo Â devs are not that many to solve all the problems that may arise, immediately.Â So I will wait and I will also try to explore VMMaker abit more see what makes it tick. And if it all fails I can fall back to old FFI. The reason why I wanted to build CogVM is basically Nativeboost's new FFI. I wanted to use the newest and badest since my project is long term and it seems both CogVM and NB are the future for both Pharo and Squeak . But as I said the very fact that my project will take years to reach version 1 since its huge, has the positive side effect that I am not in any hurry to see this work very well.Â So take your time and I will try to learn and assist any way I can. I will certainly take it slowly and enjoy the whole process ;) ________________________________ From: Esteban Lorenzano <estebanlm(a)gmail.com> To: dimitris chloupis <thekilon(a)yahoo.co.uk> Sent: Sunday, 29 January 2012, 23:52 Subject: Re: [Pharo-project] Trying to build CogVM in MacOSX 10.7 Lion I have serious doubts that this will work, but ok, I'm sending compiler :) other solution (temporary solution, of course), would be download xcode 4.0, install it, then "update" to 4.2 (I'm not happy with all of this, but well... I need time to create a proper compilation with llvm or ported gcc)Â El 29/01/2012, a las 6:12p.m., dimitris chloupis escribiÃ³: tried all the steps and generated sources when i try to make it fails here is my log > > >DIMITRISs-iMac:~ kilon$ cd cogvm >DIMITRISs-iMac:cogvm kilon$ cd blessed >DIMITRISs-iMac:blessed kilon$ cd build >DIMITRISs-iMac:build kilon$ ../codegen-scripts/extract-commit-info.sh >DIMITRISs-iMac:build kilon$ cmake . >-- The C compiler identification is GNU >-- The CXX compiler identification is GNU >-- Checking whether C compiler has -isysroot >-- Checking whether C compiler has -isysroot - yes >-- Checking whether C compiler supports OSX deployment target flag >-- Checking whether C compiler supports OSX deployment target flag - yes >-- Check for working C compiler: /usr/bin/gcc >-- Check for working C compiler: /usr/bin/gcc -- works >-- Detecting C compiler ABI info >-- Detecting C compiler ABI info - done >-- Checking whether CXX compiler has -isysroot >-- Checking whether CXX compiler has -isysroot - yes >-- Checking whether CXX compiler supports OSX deployment target flag >-- Checking whether CXX compiler supports OSX deployment target flag - yes >-- Check for working CXX compiler: /usr/bin/c++ >-- Check for working CXX compiler: /usr/bin/c++ -- works >-- Detecting CXX compiler ABI info >-- Detecting CXX compiler ABI info - done > > >Adding internal plugin: ADPCMCodecPlugin >Adding internal plugin: BMPReadWriterPlugin >Adding internal plugin: B2DPlugin >Adding internal plugin: BitBltPlugin >Adding internal plugin: ClipboardExtendedPlugin >Adding internal plugin: DSAPrims >Adding internal plugin: ZipPlugin >Adding internal plugin: DropPlugin >Adding internal plugin: FFTPlugin >Adding internal plugin: FilePlugin >Adding internal plugin: FloatArrayPlugin >Adding internal plugin: GeniePlugin >Adding internal plugin: HostWindowPlugin >Adding internal plugin: JPEGReadWriter2Plugin >Adding internal plugin: JPEGReaderPlugin >Adding internal plugin: Klatt >Adding internal plugin: LargeIntegers >Adding internal plugin: Matrix2x3Plugin >Adding internal plugin: MiscPrimitivePlugin >Adding internal plugin: RePlugin >Adding internal plugin: SecurityPlugin >Adding internal plugin: SocketPlugin >Adding internal plugin: SoundCodecPrims >Adding internal plugin: SoundPlugin >Adding internal plugin: StarSqueakPlugin >Adding internal plugin: SurfacePlugin >Adding internal plugin: UnixOSProcessPlugin >Adding external plugin: SqueakFFIPrims >Adding external plugin: IA32ABI >Adding external plugin: UUIDPlugin >Adding external plugin: FloatMathPlugin >Adding external plugin: AsynchFilePlugin >Adding external plugin: SerialPlugin >Adding external plugin: Mpeg3Plugin >Adding external plugin: CroquetPlugin >Adding external plugin: JoystickTabletPlugin >Adding external plugin: MIDIPlugin >Adding external plugin: B3DAcceleratorPlugin >Adding external plugin: LocalePlugin >Adding external plugin: ObjectiveCPlugin >Adding external plugin: QuicktimePlugin >Adding external plugin: TestOSAPlugin >Adding external plugin: FT2Plugin >-- Configuring done >-- Generating done >-- Build files have been written to: /Users/kilon/cogvm/blessed/build >DIMITRISs-iMac:build kilon$ make >Scanning dependencies of target UnixOSProcessPlugin >[ Â 1%] Building C object UnixOSProcessPlugin/CMakeFiles/UnixOSProcessPlugin.dir/Users/kilon/cogvm/blessed/src/plugins/UnixOSProcessPlugin/UnixOSProcessPlugin.c.o >cc1: error: unrecognized command line option "-arch" >cc1: error: unrecognized command line option "-arch" >cc1: error: unrecognized command line option "-arch" >make[2]: *** [UnixOSProcessPlugin/CMakeFiles/UnixOSProcessPlugin.dir/Users/kilon/cogvm/blessed/src/plugins/UnixOSProcessPlugin/UnixOSProcessPlugin.c.o] Error 1 >make[1]: *** [UnixOSProcessPlugin/CMakeFiles/UnixOSProcessPlugin.dir/all] Error 2 >make: *** [all] Error 2 >DIMITRISs-iMac:build kilon$Â > > > > > >________________________________ > From: Esteban Lorenzano <estebanlm(a)gmail.com> >To: Pharo-project(a)lists.gforge.inria.fr; dimitris chloupis <thekilon(a)yahoo.co.uk> >Sent: Sunday, 29 January 2012, 22:54 >Subject: Re: [Pharo-project] Trying to build CogVM in MacOSX 10.7 Lion > >if you have this one: i686-apple-darwin11-gcc-apple-4.2.1 >that should be the right one. > >Just create a symlink 'gcc' in /usr/bin and let's see what happens. > > > >El 29/01/2012, a las 5:50p.m., dimitris chloupis escribiÃ³: > >> it appears I was correct according to this >> >> http://ask.metafilter.com/200231/How-to-install-gcc-42-on-a-macbook-with-Xc… >> >> and a gazillion other results from google . It no longer ships with Xcode-4.2. I assume you have upgraded from 4.1 that is why you have it. >> >> Ok I am ready to try macports but how ? >> >> >> I have several gccs in macports >> >> gcc-apple-4.2 >> >> and >> >> i686-apple-darwin11-gcc-apple-4.2.1 >> >> which one and how ? >> >> From: Esteban Lorenzano <estebanlm(a)gmail.com> >> To: dimitris chloupis <thekilon(a)yahoo.co.uk> >> Sent: Sunday, 29 January 2012, 22:32 >> Subject: Re: [Pharo-project] Trying to build CogVM in MacOSX 10.7 Lion >> >> I really don't know... maybe Sean (who installed xcode from scratch recently) can confirm that. >> >> so... let's try with macports... :) >> >> best, >> Esteban >> >> El 29/01/2012, a las 5:30p.m., dimitris chloupis escribiÃ³: >> >>> in usr/bin I have i686-apple-darwin11-llvm-g++-4.2 and 686-apple-darwin11-llvm-gcc-4.2. Both are symlinks that point to the usr/llmv-gcc-4.2/bin and corresponding binaries. >>> >>> Dont know why, there is also a gcc binary in my home folder. Maybe I accidentally moved it there before the install. >>> >>> The install was sucessful as far I can tell, there were no errors. >>> >>> as I said the only thing non llvm is in macports folder which of course is not related to xcode install. I feel that I can bet serious money that the new xcode comes with only llvm compilers. Maybe I am wrong.Â >>> >>> From: Esteban Lorenzano <estebanlm(a)gmail.com> >>> To: Pharo-project(a)lists.gforge.inria.fr; dimitris chloupis <thekilon(a)yahoo.co.uk> >>> Sent: Sunday, 29 January 2012, 22:09 >>> Subject: Re: [Pharo-project] Trying to build CogVM in MacOSX 10.7 Lion >>> >>> he... connection problems... yeah, I know a lot about them :) >>> >>> well... after a successful install, I *think* you should have gcc and gcc-4.2... last one is also a symlink who points to: >>> >>> /usr/bin/i686-apple-darwin11-gcc-4.2.1 >>> >>> who should be there... is that the case? >>> >>> >>> >>> El 29/01/2012, a las 4:51p.m., dimitris chloupis escribiÃ³: >>> >>>> there is no gcc in usr/bin at all. Afterall your first command removed the only one ;) >>>> >>>> I have reinstalled XcodeÂ to be sure . My Xcode About box says its XCODE 4.2 build 4D199 >>>> >>>> no idea how to update cause I downloaded it via torrent, could not download from app store cause my connection is crapish and each time I disconnected it canceled my upload (no I could not resume, tried everything). So I had to install via torrent. >>>> >>>> >>>> >>>> From: Esteban Lorenzano <estebanlm(a)gmail.com> >>>> To: Pharo-project(a)lists.gforge.inria.fr; dimitris chloupis <thekilon(a)yahoo.co.uk> >>>> Sent: Sunday, 29 January 2012, 20:49 >>>> Subject: Re: [Pharo-project] Trying to build CogVM in MacOSX 10.7 Lion >>>> >>>> There is a problem there... if you have XCode 4.2.1 (latest), you should have that one... xcode just changed the default, it did not remove the gcc, AFAIK. >>>> >>>> which versions of gcc do you have in /usr/bin? >>>> >>>> oh, btw... is ln -s, not just ln (my mistake, but both should work) >>>> >>>> (symlink macport gcc should work, but I'm fearing there is something wrong with xcode instalation, and that's probably the reason it didn't compiled the first time, so, let's be sure about that before try the port) >>>> >>>> El 29/01/2012, a las 3:40p.m., dimitris chloupis escribiÃ³: >>>> >>>>> >>>>> >> sudo rm /usr/bin/gcc >>>>> >>>>> success ! >>>>> >>>>> >> sudo ln /usr/bin/gcc-4.2 gcc >>>>> >>>>> fail ! >>>>> >>>>> no such file >>>>> >>>>> there is a gcc symlink in developer/usr/bin that point to developer/usr/llvm-gcc-4.2/llvm-gcc-4.2 >>>>> >>>>> there is no gcc-4.2 in my Xcode folder or other folders except the gcc folder that I installed via macports following the previous tutorial that I have linked. Should I symlink macports gcc-4.2 ? >>>>> >>>>> Xcode is by default isntalled in the Developer folder >>>>> >>>>> I am open to suggestions and thanks for helping me.Â >>>>> >>>>>Â >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > >

Jan. 29, 2012

Re: [Pharo-project] loading Seaside 3.0.6.3 in Pharo 1.4

by Philippe Marschall

On 29.01.2012 21:23, Esteban Lorenzano wrote: > Hi, > > I loaded last version of seaside into a pharo 1.4 image. > Everything looks working fine, but there a couple of fixes: > > 1) > > KomLogger>>#attachTranscript > self detachTheTranscript. > ^(self streams detect: [:ea | ea isTranscriptStream] ifNone: [nil]) > ifNil: [self addStream: TranscriptStream new] > > > "TranscriptStream" is not anymore on pharo and should be replaced with ThreadSafeTranscript Are you using full Comanche or KomHttpServerLight? We moved to KomHttpServerLight because we involuntarily have to maintain it and the KomHttpServerLight code base is much smaller. KomHttpServerLight doesn't have the KomLogger class. > 2) String>>#withBlanksTrimmed is deprecated, and now it should use #trimBoth Who's sending this? I have no such senders (with KomHttpServerLight). > how can I proceed to apply this fixes into seaside (without breaking other platforms)? -> seaside-dev mailing list Cheers Philippe

Jan. 29, 2012

Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only?

by Otto Behrens

> Do you have a writeup/article describing your approach ? Some stuff in the README on the https://github.com/finworks/smallsource. Let me know what you need. I'm writing more as we speak... :-) > First question: does your system deal with packages as we know them, with extensions ? Yes, with extensions. Have not tried traits though.

Jan. 29, 2012

Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only?

by Sven Van Caekenberghe

Otto, On 29 Jan 2012, at 23:03, Otto Behrens wrote: > Hi, > > We've built a little package that allows us to save all our source in > git. We've been developing with this for 3 months now, and it's pretty > stable. I put a project on github, > https://github.com/finworks/smallsource that contains some more info > on it. Yes, there's more work to do, but there's hope. The repo > contains some examples that I just saved from the image. > > In short, we save and load all the monticello packages on our project > as smalltalk source files. We use git to merge and not monticello. We > use metacello, but watered down to essentially just dependencies. > > I just want to say thanks to all you people who put in such great > effort into Smalltalk. We are using Smalltalk to create a business and > are slowly getting somewhere. > > We've been using git for about 3 years now. This came from a need to > manage files, such as scripts, resources (images and stuff), documents > and recorded selenium (ide) tests with smalltalk code. So, we just > whacked all of this, including our monticello packages into the git > repo. > > As you can imagine, storing binary files in a git repo, especially > fairly large packages and lots of integrations / merges / versions, > grew the git repo quite a bit. We also needed to clone the git repo > all over. So we decided to give it a shot and write to files. > > It took about 2 weeks to get going and another to sort out some pain, > but the package in the smallsource repo have not changed for 3 months. > > We are 5-6 developers on the project, committing numerous times a day. > We currently have about 1100 classes (find repo -type d | wc -l gives > us 2200) and 23500 methods (find . -type f | grep -v "mcz$" | wc -l > gives us 23545) managed in this way. > > I'm keen to talk about how we can really "do the right thing" and > solve this source code management monster. I know this approach needs > work (I'll list some issues on the project, that I think needs > attention) and I also realise that there could be better approaches. > > Here's another idea: we can map class definitions and method > definitions directly to git objects. Git has a great object model > which will allow us to directly track the complete history of a method > or class definition, with commit details and what not. In a sense, I > feel that a tight integration between a smalltalk environment and git > will be a fantastic solution - something like envy, but on git, with > all the fanciness that comes with git! > > The only problem with this is a very tight coupling with git. Do we want that? > > Thanks again > Otto This sounds very interesting/promising ! Do you have a writeup/article describing your approach ? First question: does your system deal with packages as we know them, with extensions ? Sven

Jan. 29, 2012

Re: [Pharo-project] [squeak-dev] Smalltalk for small projects only?

by Sean P. DeNigris

Chris Muller-3 wrote > > A MNU is too-trivial an issue to give up on the Spoon dream Obviously. I was speaking to the over simplification that no-one-being-willing-to-give-feedback was the key impediment to a bright future, not to Spoon's value. -- View this message in context: http://forum.world.st/Smalltalk-for-small-projects-only-tp4336237p4339393.h… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 29, 2012

Re: [Pharo-project] Smalltalk for small projects only?

by Philippe Marschall

On 29.01.2012 21:12, Guido Stepken wrote: > I often discuss with Frank Lesser about Smalltalk compiler internals. He > has written a Smalltalk VM (GVM), that is written in Assembler and jits > Smalltalk directly dynamically into Intel machine code, that is *faster* > than C in normal cases, expecially when fine tuned, able to run VS, VA, > Squeak, Dolphin, Lesser Smalltalk in their own namespace, and MP!!! > Sounds strange, because of different implementations (bytecode, > callbacks...). GC runs on a 2.nd processor, what means, no more > interruptions, Real Time Availability!!! If you want, you can control > all traffic signs of NY within one Intel machine. > > He proofes, that Smalltalk, expecially Pharo is far away from being at > the end.... :-) > > (And yes, i try to convince him to take part in the "language shootout" > and make his GVM MIT license) :-) You didn't get my point. My point is tools suck until you fix them. Just saying you could fix them doesn't fix them. To rehash the argument: Me: Monticello doesn't scale Stef: we could make Monticello scale Now does this make Monticello scale? In the STPW it does. It the real world it doesn't until somebody goes there and fixes Monticello. So what are we discussing the real world or the STPW? Cheers Philippe

Jan. 29, 2012

Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only?

by Otto Behrens

Hi, We've built a little package that allows us to save all our source in git. We've been developing with this for 3 months now, and it's pretty stable. I put a project on github, https://github.com/finworks/smallsource that contains some more info on it. Yes, there's more work to do, but there's hope. The repo contains some examples that I just saved from the image. In short, we save and load all the monticello packages on our project as smalltalk source files. We use git to merge and not monticello. We use metacello, but watered down to essentially just dependencies. I just want to say thanks to all you people who put in such great effort into Smalltalk. We are using Smalltalk to create a business and are slowly getting somewhere. We've been using git for about 3 years now. This came from a need to manage files, such as scripts, resources (images and stuff), documents and recorded selenium (ide) tests with smalltalk code. So, we just whacked all of this, including our monticello packages into the git repo. As you can imagine, storing binary files in a git repo, especially fairly large packages and lots of integrations / merges / versions, grew the git repo quite a bit. We also needed to clone the git repo all over. So we decided to give it a shot and write to files. It took about 2 weeks to get going and another to sort out some pain, but the package in the smallsource repo have not changed for 3 months. We are 5-6 developers on the project, committing numerous times a day. We currently have about 1100 classes (find repo -type d | wc -l gives us 2200) and 23500 methods (find . -type f | grep -v "mcz$" | wc -l gives us 23545) managed in this way. I'm keen to talk about how we can really "do the right thing" and solve this source code management monster. I know this approach needs work (I'll list some issues on the project, that I think needs attention) and I also realise that there could be better approaches. Here's another idea: we can map class definitions and method definitions directly to git objects. Git has a great object model which will allow us to directly track the complete history of a method or class definition, with commit details and what not. In a sense, I feel that a tight integration between a smalltalk environment and git will be a fantastic solution - something like envy, but on git, with all the fanciness that comes with git! The only problem with this is a very tight coupling with git. Do we want that? Thanks again Otto

Jan. 29, 2012

Re: [Pharo-project] Smalltalk for small projects only?

by Philippe Marschall

On 29.01.2012 22:31, Chris Muller wrote: > But the goal of making the image smaller is congruent with the goal of > making Morphic smaller, which would be congruent with the desire for > Monticello to be "scalable". What are you talking about? I chose Morphic because it was the first package I found that had more than a dozen classes. > So the solution should be smaller > packages, not more and bigger tools. You should chose the package size on what makes sense from a software design point of view, not what the scalability limit of your tools is. > Besides, the measure of scale you've chosen is an build / > initialization step, which can much more afford to be "slow", > especially if the dream is to just have it sit and build 24 hours a > day. > > A better non-scaling measure to recognize in Monticello, IMO, is using > FileBased repositories, which require enumeration of an ever-growing > number of versions for many of its operations. > > Using a database-backed MC repository solves that. What are we discussing here? What is or the STPF? Cheers Philippe

Jan. 29, 2012

Re: [Pharo-project] PseudoContext?

by Nicolas Cellier

I don't see any PseudoContext in squeak trunk, you can reasonably not afford to be dirtier ;) 2012/1/29 Marcus Denker <marcus.denker(a)inria.fr>: > > On Jan 29, 2012, at 6:02 PM, StÃ©phane Ducasse wrote: > >> Hi >> >> I have the impression that PseudoContext is not used anymore. At least compact class array and special object array >> do not use it anymore. So what is the use for this class? >> > I think it was only used by Ian's original Jitter... which means 10 years unused. > We should remove it. > > Â Â Â Â Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > >

Jan. 29, 2012

Re: [Pharo-project] FSFileSystem: modification date

by Marcus Denker

On Jan 27, 2012, at 9:42 PM, Camillo Bruni wrote: > Hi Deby, > > Open a bug report :) I think the memory FS should handle the modification / creation dates exactly as it would on disk... > There is a bug entry here already: http://code.google.com/p/pharo/issues/detail?id=3154 -- Marcus Denker -- http://marcusdenker.de

Jan. 29, 2012