- Pharo-dev - lists.pharo.org

[Pharo-project] Exception chapter PBE2
by Norbert Hartl Jan. 24, 2012

Jan. 24, 2012

I've read the exception chapter of the new PBE. And I really enjoyed reading it. I find it easy to understand and well-balanced between how-to-use and how-it-works. Great work! Norbert P.S.: I thought I've found a typo where a message sentTo: is used. But then I discovered there is indeed a message called sentTo: Unfortunately I didn't get the difference to sendTo: :)

3 2

[Pharo-project] FOSDEM2012 smalltalk devroom 5 feb, sprint 4 feb
by Stephan Eggermont Jan. 24, 2012

Jan. 24, 2012

Feb 4-5 2012 Brussels hosts FOSDEM2012, the free and open software developers european meeting. Sunday there will be a smalltalk devroom (AW 1.126) with a number of interesting presentations. 09:30 Norbert Hartl, Take a small REST. Simple approaches for REST in smalltalk 10:00 Stephane Ducasse, Marcus Denker, The next steps for the Pharo Vision 11:00 Laurent Laffont, John Thornton, Amber, the Smalltalk for web developers 12:00 Nick Ager, An introduction to jQuery Mobile 12:30 Stefan Marr, RoarVM, Sly 13:00 David Chisnall, Compiling Smalltalk to fast native Code 13:30 Craig Latta, Spoon 14:00 Stephan Eggermont, Willem van den Ende, Diego Lont, Back to the future, (re)learn smalltalk (till 16:30). http://fosdem.org/2012/schedule/track/smalltalk_devroom As there is no devroom on saturday, the VUB has kindly offered to organise a sprint. There will be a room available at walking distance from FOSDEM. Stephan

2 1

[Pharo-project] ZipWriteStream error when closing it twice. Normal?
by Mariano Martinez Peck Jan. 24, 2012

Jan. 24, 2012

Hi guys. I found that GZipWriteStream throws an error when closing it twice. Example: | aStream zipStream | aStream := ByteArray new writeStream binary. zipStream := GZipWriteStream on: aStream. zipStream close. zipStream close. All the streams I know do not throw an error in that case. And moreoever, it gets things complicated when using #on:do:. For example: FileStream forceNewFileNamed: testFileName do: [ :stream | GZipWriteStream on: stream binary do: [ :gzipStream | FLSerializer newDefault serialize: anObject on: gzipStream ] ]. In thise case, FLSerializer closes the stream at the end. No matter whether Fuel should do that or not, the thing is that in this I have the mentioned problem. So...my question is, is this a bug? if it is, do you have a better idea that changing #close to this: ZipWriteStream >> close literals isNil ifTrue: [ "#initialize sets this instVar to a specific value. #release puts it in nil, and #release is called from #flushBlock: which is called from #close:. Therefore, if it is nil, it means the stream has already been closed. If we try to close it twice, #flushBlock will throw an error because its instance variables are with nil" ^ self] self deflateBlock. self flushBlock: true. encoder close. -- Mariano http://marianopeck.wordpress.com

1 0

Re: [Pharo-project] Fwd: [squeak-dev] ANN: OpenGL + NativeBoost + Mac ==> success
by Fernando Olivero Jan. 24, 2012

Jan. 24, 2012

Check out the most recent mail to this mailing list by Bert Freudenberg, were he explains the inner workings of the Ballon3D plugin, to achieve what you propose. The other means would be to change the VM, and bypass completely the bitmapped "Display", and provide Events+a windowed OpenGL context ,to were we can draw within the image. Check out recent emails from myself in the list,the thread titled "decoupling the vm: UI and interpretation". Fernando On Tue, Jan 24, 2012 at 3:04 AM, Lawson English <lenglish5(a)cox.net> wrote: > Kool. So how could I make the entire World a drawing surface so that I > could use the OpenGL drawing throughout the entire squeak/pharo OS > window, instead of within another window? > > Could a 2D/3D mashup like I have in this video be accomplished? The fps > is too slow to be useable for most things, at this point: > http://www.youtube.com/watch?v=nSLZKIXeXR4 > > On 1/23/12 3:00 PM, Hans-Martin Mosner wrote: >> Am 23.01.2012 18:03, schrieb Lawson English: >>> Is there a way to directly draw to the system window using OpenGL so that intermediate software blitting is eliminated? >>> >> The opengl context is already drawing directly to the screen (or rather, to the back buffer managed by opengl). >> There is no intermediate software blitting involved AFAIK. >> >> Cheers, >> Hans-Martin >> >> > >

1 0

[Pharo-project] is there a way to avoid all the #tryNamedPrimitive:with: * in ProtoObject
by Mariano Martinez Peck Jan. 24, 2012

Jan. 24, 2012

Hi guys. I usually like to take a look to ProtoObject and see what is really needed for the minimal object. But having 30% of the methods being #tryNamedPrimitive:with: * is not fun. So...I wonder, do you think there could be another way so that to avoid having all those methods in ProtoObject ? Thanks -- Mariano http://marianopeck.wordpress.com

3 7

Re: [Pharo-project] Fwd: [squeak-dev] ANN: OpenGL + NativeBoost + Mac ==> success
by Lawson English Jan. 24, 2012

Jan. 24, 2012

Kool. So how could I make the entire World a drawing surface so that I could use the OpenGL drawing throughout the entire squeak/pharo OS window, instead of within another window? Could a 2D/3D mashup like I have in this video be accomplished? The fps is too slow to be useable for most things, at this point: http://www.youtube.com/watch?v=nSLZKIXeXR4 On 1/23/12 3:00 PM, Hans-Martin Mosner wrote: > Am 23.01.2012 18:03, schrieb Lawson English: >> Is there a way to directly draw to the system window using OpenGL so that intermediate software blitting is eliminated? >> > The opengl context is already drawing directly to the screen (or rather, to the back buffer managed by opengl). > There is no intermediate software blitting involved AFAIK. > > Cheers, > Hans-Martin > >

1 0

[Pharo-project] System Update auto Merge
by Camillo Bruni Jan. 23, 2012

Jan. 23, 2012

Hi everyone, I wonder if it would make sense if System Update would perform auto merging? I think if there are no merge conflicts you should not get any notifications from System Update. In any case I will program an Option for this in the Setting Browser. best cami

2 2

[Pharo-project] Live Ruby on rails tutorial sites
by Lawson English Jan. 23, 2012

Jan. 23, 2012

This is the kind of thing that seaside needs to have to attract more people. http://railsforzombies.org/ Lawson

1 0

[Pharo-project] Fwd: [squeak-dev] ANN: OpenGL + NativeBoost + Mac ==> success
by Igor Stasenko Jan. 23, 2012

Jan. 23, 2012

---------- Forwarded message ---------- From: Igor Stasenko <siguctua(a)gmail.com> Date: 23 January 2012 01:26 Subject: Re: [squeak-dev] ANN: OpenGL + NativeBoost + Mac ==> success To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> On 22 January 2012 15:13, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Jan 22, 2012, at 1:29 PM, Lawson English wrote: > >> On 1/22/12 3:07 AM, StÃ©phane Ducasse wrote: >>> did you notice that you can save the image in the middle of the animation and it will continue on restart :) >> >> >> I didn't notice that. However, a there were several things I did notice: >> >> 1) you could have more than one GL Morph open at once. However, if you resized one Â GL morph window, the drawing area of the other would resize. > > Indeed :) > yeah. it looks like i don't switching current GL context when resizing, which affects currently active context. >> 2) large windows tended to leave a lot of artifacts behind during movement (the video shows this towards the end). there is two "modes" to blit on Morphic display - one is just copy directly to Display, and another is to separate form and then draw that form as usual. so, these artefact is not related to OpenGL per se, but mainly to how you make rendered results appear integrated in morphic. >> 3) creating more than one window would sometimes evoke the debugger. Proceeding eventually would create GL morph windows but they might or might not have valid contents. >> 4) saving occasionally caused errors, but the save continued anyway and restarting the image didn't show any problems. >> everything is in your hands :) >> I see an awful lot of potential for OpenGL on Squeak/Pharo. >> >> Of course, being involved iwth SiliconSqueak, I hope that we can transcend all current technologies and eventually create something truly different and better. >> >> Lawson >> -- Best regards, Igor Stasenko. -- Best regards, Igor Stasenko.

2 1

[Pharo-project] Ann: OmniBrowser stable for 1.4 with RB
by Guillermo Polito Jan. 23, 2012

Jan. 23, 2012

I've updated the configuration of OmniBrowser so It can load with the last version of RB. (ConfigurationOfOmniBrowser project version: #stable) load: #( 'Dev' 'Dev Tests'). BTW, I've fixed a deprecation on RB (#withBlanksTrimmed -> #trimBoth) and posted it into PharoTaskForces, since I don't have grants to write into PharoRB. All tests are green and It's working fine :). This version is freezed for anyone who wants to use it. I'll be working to update OB to Lukas's latest chanes from now on. Bye! Guille

7 26