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

Re: [Pharo-project] NativeBoost and NBOpenGL on Mac?
by Fernando Olivero Jan. 11, 2012

Jan. 11, 2012

I've developed a CocoaUI app, which implements the example you copied. A cocoa window, with a custom NSView, which renders an OpenGL surface. The app also catches events, and notifies it via sockets. My idea is to render within Pharo to a frame buffer object(offscreen rendering), and communicate the redisplay to the cocoa app via sockets (IPC). So we can code all the UI in Smalltalk, using offscreen rendering as a means to draw to a native OS X window. I will continue experimenting with this approach, to assess its performance and usability. Wether IPC via sockets is fast enough, amongst other technical challenges. Yes, i noticed two that the OpenGL info in the Mac, returns 'APPLE SOFTWARE RENDERER 2.1". Surely we can find a way to solve this problem, i will look into Lawson's link. Fernando pd: Enjoy the vacations Igor, have a pint or two. On Wed, Jan 11, 2012 at 1:21 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 10 January 2012 21:28, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> thanks >> >> May be this page is interesting: http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conce… >> >> Igor how is london :) ? >> >> Crowded? > > like hell. :) > Kiev is more or less same in this regard, so i already having immunity > > Yes, i will definitely get back to this issue, once i return from vacation. > And now i should stop reading and replying mails and spend time on > just resting :) > > -- > Best regards, > Igor Stasenko. >

4 4

[Pharo-project] Suggestion Note:
by S Krish Jan. 11, 2012

Jan. 11, 2012

Should raise this as a separate artifact and probably send out my fixes ( currently these are hacks). Many of the other logics do not work as per standard practices... from other comp usage.. windows/ linux.. * FileOut is silent and saves to the resources folder ... no chance of intervention while it goes out.. also overwrites silently.. Simple save/ saveas popup menu would help .. when reqd. * Image saveAs : only image name is taken.. no folder selection... though one can give a full path in the text editor. * remember the last navigated path in file open/ save dialogs * Monticello save is incremental and quickly builds up a huge stack of files.. need to optimize this.. autosave packages marked to a given default single file overwriting it.. reduce multiple mc saves to the minimum when you really need to version a new base. Oddball issues: * Morph/ dialog window onClick opens another dialog, sends this parent down right back in the stack of windows.. not just push the new dialog as top window. So when this new dialog closes.. you may have to dig out your old morph back if its gone behind code windows.. etc.. On Wed, Jan 4, 2012 at 11:31 AM, S Krish <krishnamachari.sudhakar(a)gmail.com>wrote: > No. > > > On Tue, Jan 3, 2012 at 9:02 PM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> But the interface should bark instead of forgetting a change silently >> when we open/close a preference (Oups setting) node... >> Does it now ? >> >> Nicolas >> >> 2012/1/3 S Krish <krishnamachari.sudhakar(a)gmail.com>: >> > Thats already there.. >> > >> > it does show the highlighted background and also a tip on the text area >> > below to accept on cr. But as lazy as we are we do not notice hints >> obvious >> > in the face of habits. >> > >> > >> > On Tue, Jan 3, 2012 at 6:27 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> >> Mariano Martinez Peck wrote: >> >>> >> >>> On Tue, Jan 3, 2012 at 1:11 PM, Alain Plantec >> >>> <alain.plantec(a)yahoo.com>wrote: >> >>> >> >>> >> >>>> >> >>>> Le 03/01/2012 11:57, S Krish a Ã©crit : >> >>>> >> >>>> This works... >> >>>> >> >>>>> >> >>>>> Guess I should have tried that.. >> >>>>> >> >>>>> >> >>>> >> >>>> thanks. >> >>>> but you are not the first one to forget to enter a cr. >> >>>> >> >>>> >> >>> >> >>> >> >>> Yes, I was the first one!!! I remember I have reported the same ;) >> >>> >> >>> >> >> >> >> A small thought - the field background might be made to change colour >> >> during entry until it is accepted by <cr>. >> >> >> > >> >> >

3 2

Re: [Pharo-project] [COTDC] 103 - ZLibWriteStream
by Max Leske Jan. 11, 2012

Jan. 11, 2012

I use the zlib implementation of the deflate algorithm to compress a ByteArray. See http://en.wikipedia.org/wiki/DEFLATE for details on the deflate algorithm. This is how you get a compressed ByteArray from your input: zipStream := ZLibWriteStream on: (ByteArray new). zipStream nextPutAll: myByteArray; close. compressed := zipStream encodedStream contents. On 10.01.2012, at 21:36, sean(a)clipperadams.com wrote: > 102 classes done > 794 classes remaining > Continuing in Compression... > > Today: ZLibWriteStream > > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > p.s. this message was sent from a pharo image. Did you know you could easily do that?! >

3 2

Re: [Pharo-project] [COTDC] 104 - ZLibWriteStream
by Alexandre Bergel Jan. 11, 2012

Jan. 11, 2012

I just had a look at ZLibWriteStream. This class is really cryptic. Deep knowledge about the zip format is needed. Maybe something like: -=-=-=-=-=-=-=-=-=-=-=-= ZLib is a data compression algorithm. According to Wikipedia, "this algorithm provides good compression on a wide variety of data with minimal use of system resources." The class can be used that way: | writer | writer := ZLibWriteStream on: String new. writer nextPutAll: 'Hello World'. writer close. writer encodedStream contents -=-=-=-=-=-=-=-=-=-=-=-= Alexandre On 11 Jan 2012, at 10:14, sean(a)clipperadams.com wrote: > 103 classes done > 793 classes remaining > Continuing in Compression... > > Today: ZLibWriteStream > > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > p.s. this message was sent from a pharo image. Did you know you could easily do that?! > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

1 0

[Pharo-project] [COTDC] 104 - ZLibWriteStream
by sean＠clipperadams.com Jan. 11, 2012

Jan. 11, 2012

103 classes done 793 classes remaining Continuing in Compression... Today: ZLibWriteStream Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest p.s. this message was sent from a pharo image. Did you know you could easily do that?!

1 0

Re: [Pharo-project] [COTDC] 101 - TarArchiveMember
by Alexandre Bergel Jan. 11, 2012

Jan. 11, 2012

This class should be removed. By not defining any method (instance and class side), it is useless. Alexandre On 7 Jan 2012, at 23:26, sean(a)clipperadams.com wrote: > 100 classes done > 796 classes remaining > Continuing in Compression... > > Today: TarArchiveMember > > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > p.s. this message was sent from a pharo image. Did you know you could easily do that?! > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 1

[Pharo-project] DateAndTime, timezones and Fuel
by Mariano Martinez Peck Jan. 11, 2012

Jan. 11, 2012

Hi guys. I have a simple question. When we are serializing DateAndTime with fuel, we serialize its 4 instance variables: 'seconds offset jdn nanos'. And then, during materialization, we recreate them. I know that all instances of DateAndTime have their instVar 'offset' pointing to the local timezone offset, that is, DateAndTime localTimeZone offset. In fuel, during materialization, we recreate those offsets. So all materialized instances of DateAndTime will have their own (different) instance of Duration in the slot 'offset'. On the one hand, I think this is necessary becase you can materialize in a different image with different time zone, so having the timezone is mandatory. What I don't know, and this is the question, is if the timezone is the same between serialization and materialization image, MUST all materializated DateAndTime point to the same offset? or it is just an optimization that they all point to the same? Thanks in advance, -- Mariano http://marianopeck.wordpress.com

2 1

Jan. 11, 2012

Hi guys I wish you good health (because at the end this is the most important and when we are going well we do not estimate how cool it is). Then lot of fun and business. Stef

6 7

[Pharo-project] Squeaksource is... up, but just barely
by Sean P. DeNigris Jan. 11, 2012

Jan. 11, 2012

It's very... very... slow... (enough that Metacello loads are timing out) -- View this message in context: http://forum.world.st/Squeaksource-is-up-but-just-barely-tp4283895p4283895.… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

2 2

[Pharo-project] NativeBoost and NBOpenGL on Mac?
by Lawson English Jan. 11, 2012

Jan. 11, 2012

I've had problems installing NativeBoost on Squeak, but it worked reasonably well installing on a Mac. However, TestRunner failed while running the callback tests. This may or may not have anything to do with trying to work with NBOpenGL, which also installs fine on Pharo (but not squeak). Basically: GLViewportMorph new "useOwnForm: true;" openInWorld fails with Error: function unavailable It fails during this: hInst := NativeBoostWin32 getVMModuleHandle. which I assume means that Mac OS X is still not supported? Any workarounds available yet? I should point out that my little kludgey youtube demo of integrating OpenGL and the squeak IDE has generated 10x as many hits per day as the next most popular video in my tutorial series on squeak. I should also point out that when I demo pier and seaside I use Pharo and explicitly point out I'm using Pharo, so the Pharo community might benefit quite a bit from me being able to use NBOpenGL on the Mac... L.

4 5