- Pharo-dev - lists.pharo.org

Re: [Pharo-project] recompiling class

by StÃ©phane Ducasse

>> Soon we will be able to remove FileDirectory :) > > Yippppppppppie!!!!! even more than that :)

June 12, 2012

Re: [Pharo-project] [PLP] News

by Santiago Bragagnolo

Here is a related release-post :) http://concretetypeinference.blogspot.com.ar/2012/06/metacello-paullepoulpe… 2012/6/12 Santiago Bragagnolo <santiagobragagnolo(a)gmail.com> > > PaulLePoulpe Logger is now working and tested on Pharo 1.3 core; 1.4 > and 2.0, and working with two red tests at Pharo 1.2 core. The two red > tests are related with an announcement issue. But it dont interfere with > the work, so, it works. > > I'm using it actively in ConcreteTypeInference and KwisatzHaderach > projects swiching configurations depending on which project im working, and > work perfect. > > That's why i decided to make the first version. > > Gofer new > url: 'http://ss3.gemstone.com/ss/PaulLePoulpe'; > package: 'ConfigurationOfPaulLePoulpe'; > load. > > ( (Smalltalk at: #ConfigurationOfPaulLePoulpe) project version:'1.0' ) > load > > >

June 12, 2012

Re: [Pharo-project] who can have a look at Issue 5913: Remove Squeak epoch

by Eliot Miranda

On Mon, Jun 11, 2012 at 7:15 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > Do we all agree that standardizing on the Unix Epoch is the way to go? No :) > The > argument on the squeak list seemed to be: > - the squeak epoch has a certain beauty to it, being the turn of the > century > vs > - why reinvent the wheel? Everybody already knows what the unix epoch is > (e.g. you can point them to Wikipedia) > > The full discussion is here: > > http://forum.world.st/Re-Pharo-project-Epoch-returns-local-offset-td4630581… > > The main thing is to make sure that whatever we use is based on UTC and not > local time. > > So - two options > - PharoOffset := 1 January, 1901 UTC > - Unix offset > > Also, whatever we change it to (and IMHO it really needs to be changed), I > think existing live objects from previous Pharos (e.g. that are > materialized > with fuel) may be invalid (like the recent zip/mcz consequences) > > -- > View this message in context: > http://forum.world.st/who-can-have-a-look-at-Issue-5913-Remove-Squeak-epoch… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- best, Eliot

June 12, 2012

Re: [Pharo-project] DBXTalk & seaside / success in Pier one-click / my 1.4 woes follow-up

by Cameron Sanders

Great, Thanks for the feedback! Good points. I appreciate it. Ciao, Cam On Mon, Jun 11, 2012 at 11:27 PM, Yanni Chiu <yanni(a)rogers.com> wrote: > On 11/06/12 10:35 PM, Cameron Sanders wrote: > >> Do you need 1.4, and why? -- if you do not mind sharing. >> > > I was building on 1.3, and had a second automated build which tracked > 1.4. Periodically, I would manually update the 1.4 base image of the > build to the then latest 1.4. Each of the builds would load the > framework packages I needed, then load my code base. > > This way I could see problems with the frameworks or my code, as 1.4 > progressed. At some point 1.4 was stable enough that I switched over > (about 6 months ago). > > ... I only recently abandoned my Pharo-1.2 one-click derived image >> when I had troubles connecting to a DB. I figured it was time to do a >> complete upgrade. But it has turned into a nightmare, and my project >> has hit a standstill, >> > > Yep, you don't want to be caught by surprise, when upgrading. > > Pending your answers to my query about why you chose 1.4 over 1.3, I >> will start fresh again. >> > > In your situation, I would choose 1.4, because Seaside, Magritte2/3, > DBXTalk should work on 1.4 or will be fixed to work on 1.4 - which may not > hold true (i.e. the fixing) for 1.3. AFAIK, unless you're heavily attached > to Omnibrowser, then there is no reason to use 1.3. > > >

June 12, 2012

[Pharo-project] [PLP] News

by Santiago Bragagnolo

PaulLePoulpe Logger is now working and tested on Pharo 1.3 core; 1.4 and 2.0, and working with two red tests at Pharo 1.2 core. The two red tests are related with an announcement issue. But it dont interfere with the work, so, it works. I'm using it actively in ConcreteTypeInference and KwisatzHaderach projects swiching configurations depending on which project im working, and work perfect. That's why i decided to make the first version. Gofer new url: 'http://ss3.gemstone.com/ss/PaulLePoulpe'; package: 'ConfigurationOfPaulLePoulpe'; load. ( (Smalltalk at: #ConfigurationOfPaulLePoulpe) project version:'1.0' ) load

June 12, 2012

Re: [Pharo-project] DBXTalk & seaside / success in Pier one-click / my 1.4 woes follow-up

by Yanni Chiu

On 11/06/12 10:35 PM, Cameron Sanders wrote: > Do you need 1.4, and why? -- if you do not mind sharing. I was building on 1.3, and had a second automated build which tracked 1.4. Periodically, I would manually update the 1.4 base image of the build to the then latest 1.4. Each of the builds would load the framework packages I needed, then load my code base. This way I could see problems with the frameworks or my code, as 1.4 progressed. At some point 1.4 was stable enough that I switched over (about 6 months ago). > ... I only recently abandoned my Pharo-1.2 one-click derived image > when I had troubles connecting to a DB. I figured it was time to do a > complete upgrade. But it has turned into a nightmare, and my project > has hit a standstill, Yep, you don't want to be caught by surprise, when upgrading. > Pending your answers to my query about why you chose 1.4 over 1.3, I > will start fresh again. In your situation, I would choose 1.4, because Seaside, Magritte2/3, DBXTalk should work on 1.4 or will be fixed to work on 1.4 - which may not hold true (i.e. the fixing) for 1.3. AFAIK, unless you're heavily attached to Omnibrowser, then there is no reason to use 1.3.

June 12, 2012

Re: [Pharo-project] Pharo 2.0 Jenkins build failing

by Sean P. DeNigris

Sean P. DeNigris wrote > > the latest Cog Jit VM on Jenkins crashes when doing this update. The > latest Jenkins Stack VM works fine. > Disregard that. OS X was picking up an old vm on my system. The latest Jit and Stack VMs both work. -- View this message in context: http://forum.world.st/Pharo-2-0-Jenkins-build-failing-tp4634306p4634406.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 12, 2012

Re: [Pharo-project] DBXTalk & seaside / success in Pier one-click / my 1.4 woes follow-up

by Cameron Sanders

Yanni, Thanks! > > http://jenkins.lukas-renggli.**ch/view/Seaside%203.0/<http://jenkins.lukas-renggli.ch/view/Seaside%203.0/> > > On that site is a Pier3/Margritte3/Seaside-3.1 build as well. > Oh, maybe I will try that as a starting point. Thanks! > > However, AFAICT, all the builds are based on Pharo-1.3, which may be an > issue for you. I want to use Seaside, Magritte, Fuel (as a back-up storage facility, though primary right now), and Glorp via DBXTalk for relational DB I/O. That's my goal. Perhaps you are right and I am too early at adopting DBXTalk. It looks like it should simplify some of the DB storage. > I build my image from Pharo-1.4, adding Seaside-3.0, Magritte2, Pier2. > I do not need Pier per se. Rather, I simply had no images where the basic Magritte tutorials worked. None of them worked properly right out of the box. But you are saying that Magritte2 in Pharo-1.4, with Seaside 3.0 works together... ... ... so I will try it again. Do you need 1.4, and why? -- if you do not mind sharing. - Let me say: because these configuration problems can be such a pain, especially when one is not aware of the nuances of various packages one might want to adopt, I only recently abandoned my Pharo-1.2 one-click derived image when I had troubles connecting to a DB. I figured it was time to do a complete upgrade. But it has turned into a nightmare, and my project has hit a standstill, ((Smalltalk at: #ConfigurationOfFuel) project version: '1.8') >> load. >> > > I use version 1.7, but because I don't want the other packages in the > image, I only load: > > FuelTests-MartinDias.157.mcz > Fuel-MartinDias.479.mcz > Thank you! > > I've not tried the 1.8 version yet. If you're having trouble with Fuel, > you might want to load and run the tests. > In 1.4 Fuel worked "out of the box", but in the Pier based image, it did not. > > > Thanks for any insight you can offer in advance. > > Whenever I add a new framework, I start from my base image which has all > the frameworks that I currently use. Then I load and run the tests for the > new framework I want to use. If there are problems.... > Pending your answers to my query about why you chose 1.4 over 1.3, I will start fresh again. Cheers & Thanks, Cam

June 12, 2012

Re: [Pharo-project] who can have a look at Issue 5913: Remove Squeak epoch

by Sean P. DeNigris

Do we all agree that standardizing on the Unix Epoch is the way to go? The argument on the squeak list seemed to be: - the squeak epoch has a certain beauty to it, being the turn of the century vs - why reinvent the wheel? Everybody already knows what the unix epoch is (e.g. you can point them to Wikipedia) The full discussion is here: http://forum.world.st/Re-Pharo-project-Epoch-returns-local-offset-td4630581… The main thing is to make sure that whatever we use is based on UTC and not local time. So - two options - PharoOffset := 1 January, 1901 UTC - Unix offset Also, whatever we change it to (and IMHO it really needs to be changed), I think existing live objects from previous Pharos (e.g. that are materialized with fuel) may be invalid (like the recent zip/mcz consequences) -- View this message in context: http://forum.world.st/who-can-have-a-look-at-Issue-5913-Remove-Squeak-epoch… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 12, 2012

Re: [Pharo-project] DBXTalk & seaside / success in Pier one-click / my 1.4 woes follow-up

by Yanni Chiu

On 11/06/12 7:39 PM, Cameron Sanders wrote: > > My Pier download was what was available on Saturday at > http://www.piercms.com/download. I thought you were referring to a build from: http://jenkins.lukas-renggli.ch/view/Seaside%203.0/ On that site is a Pier3/Margritte3/Seaside-3.1 build as well. However, AFAICT, all the builds are based on Pharo-1.3, which may be an issue for you. I build my image from Pharo-1.4, adding Seaside-3.0, Magritte2, Pier2. > Then as I noted in that post, I pulled > in DBXTalk according to specs on http://dbxtalk.smallworks.com.ar/Download/. I've used an earlier Glorp port, without problem, but don't use Glorp anymore. I've never used the latest DBXTalk. The Phoseydon scaffolding seems interesting, but you might want to ask the authors what their opinion is on its readiness (the last I remember, from a year or two ago, is was a first release). Note that Magritte3 was done earlier this year, so you may have some issues there. > *What version Magritte should I be using?* The one that works for you :). Seriously though, Pier seems to be okay with either Magritte version, so whichever one Phoseydon needs will settle it - IIUC, Phoseydon uses Magritte, but I'm too lazy to check at the moment. > As an aside, in a 1.4 build, I pulled in Magritte3 via the following, > and that fixed some name conflicts. What name conflicts did you have? What tools had the conflicts? One of the key "fixes" of Magritte3 was to eliminate overloading of the #description method. > Is this the proper way to load it to work with seaside? That's the way I would load it (but I'd leave off the Morphic stuff). > ((Smalltalk at: #ConfigurationOfFuel) project version: '1.8') > load. I use version 1.7, but because I don't want the other packages in the image, I only load: FuelTests-MartinDias.157.mcz Fuel-MartinDias.479.mcz I've not tried the 1.8 version yet. If you're having trouble with Fuel, you might want to load and run the tests. > Thanks for any insight you can offer in advance. Whenever I add a new framework, I start from my base image which has all the frameworks that I currently use. Then I load and run the tests for the new framework I want to use. If there are problems, I then start from a basic Pharo image (plus any pre-req packages for the new framework). You should not have to do this, unless you are using frameworks that are relatively new, or you're using a newer Pharo image.

June 12, 2012