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

Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

by Michael Rueger

On 1/29/2010 6:28 PM, StÃ©phane Ducasse wrote: > Mike > > do you have some cycles to help here? let me see what I can come up with :-) Michael

Jan. 29, 2010

Re: [Pharo-project] video in Pharo

by John M McIntosh

I did the GStreamer plugin for Etoys ala OLPC The problem is you can't install the GStreamer software on a mac in a user friendly manner. Having to drop to the terminal session, install MacPorts by doing sudo ports install gstreamer just won't cut it. Reusing the audio/video framework we did for Sophie would be a far better thing. It has a set of abstract classes to deal with audio, video, audio/video. Concrete classes then provide the ability to play media from a set point, with controls to play/stop/rewind. Audio uses the Squeak sound system and various decoders, video would work it's way thru quicktime, mpegplayer, oggplayer. You just fed it a URL, and cmds, like play... On 2010-01-29, at 7:43 AM, Hilaire Fernandes wrote: > I remember about the development of a Gstreamer plugin in 2008. > Don't know its status now. > > Hilaire -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 29, 2010

Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

by StÃ©phane Ducasse

Mike do you have some cycles to help here? Stef On Jan 29, 2010, at 1:23 PM, Michael Rueger wrote: > On 1/29/2010 1:08 PM, Adrian Lienhard wrote: >> Do I understand correctly?: ipv6 issues are a VM problem, hence not >> directly related to Pharo. But #useOldNetwork does not work as >> advertised in new network implementation because it still uses ipv6 >> code/primitives. >> >> Hence, should we just roll back the network changes and use the old >> code as in Squeak 3.9, which, as far as I can tell, works well? > > > Apologies for coming in a bit late into the discussion. > > The new network plugin/code was orignally done by Ian and mangled by > myself (with contributions by Bert and Yoshiki IIRC) to be used in etoys > as OLPC is IPv6 only. So would be worthwhile checking the etoys network > code. > > Idea behind getting the code into Pharo was to enable more than the > really outdated and bare bones network access available through the old > network code. > That the new stuff still doesn't work is a shame, but IMHO we should fix > it rather than throwing it out. > > Patching the current code to allow use of the old network stuff would > buy us time to fix the new code. > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 29, 2010

[Pharo-project] Fwd: [Esug-list] 2 young Smalltalk developers for Germany

by Mariano Martinez Peck

Ok...it is not Pharo, but it is Smalltalk ! ---------- Forwarded message ---------- From: Nowak, Helge <hnowak(a)cincom.com> Date: Fri, Jan 29, 2010 at 5:37 PM Subject: [Esug-list] 2 young Smalltalk developers for Germany To: esug-list(a)lists.esug.org, vwnc(a)cs.uiuc.edu Dear Smalltalkers, one of our customers looks out for 2 young Smalltalkers for his experienced team to carry Smalltalk into the future at his company. German is a must. Please forward this message to anybody who you think might be interested. People interested should email me. Iâll put you in direct contact with our customer. Thank you in advance! Helge **************************************************************** *Helge K. Nowak* Technical Account Manager Cincom Smalltalk Cincom Systems GmbH & Co. oHG Am Kronberger Hang 4 D-65824 Schwalbach/Ts. Tel.: +49-(0)89-89664494 Mobil: +49-(0)172-7400402 Fax: +49-(0)89-89664495 Email: mailto:hnowak@cincom.com <hnowak(a)cincom.com> Web: http://www.cincom.com <http://smalltalk.cincom.com> *All about Cincom Smalltalk:* http://www.cincomsmalltalk.com <http://smalltalk.cincom.com> *A standpoint is an intellectual horizon of radius zero.* *-- Albert Einstein* GeschÃ¤ftsfÃ¼hrer/Managing Directors: Thomas M. Nies, Gerald L. Shawhan oHG mit Sitz/based in Schwalbach/Ts. (Amtsgericht KÃ¶nigstein/Ts. HRA 2653) Pers. haftender Gesellschafter/Partner liable to unlimited extent: Cincom Systems Verwaltungsgesellschaft mbH (Amtsgericht KÃ¶nigstein/Ts. HRB 5069)** **************************************************************** _______________________________________________ Esug-list mailing list Esug-list(a)lists.esug.org http://lists.esug.org/listinfo/esug-list

Jan. 29, 2010

Re: [Pharo-project] Cycle dependency between ImageSegment and Multilingual

by Marcus Denker

On Jan 29, 2010, at 4:59 PM, Mariano Martinez Peck wrote: > Hi folks. Jannik pointed to me a cycle dependency between ImageSegment and Multilingual. > > When you create a segment, there is a way to export the complete segment (segment in itself but also the outpointers) to a file, using SmartRefStream (ImageSegment >> writeForExportOn: ) > > Now...you can load the that file in another image. When this is done, SmartRefStream calls the method comeFullyUpOnReload: > > So.... in ImageSegment >> comeFullyUpOnReload: we a bigggggg method, which this lines (a part, of course): > > importedObject is just one of all the objects that are in the SmartRefStream. > > > (importedObject isKindOf: TTCFontSet) ifTrue: [ > existing := TTCFontSet familyName: > importedObject familyName > pointSize: > importedObject pointSize. "supplies default" > existing == importedObject ifFalse: > [importedObject becomeForward: existing]. > ]. > > > Does someone know why this piece of code should be necessary ? Of course, and I guess all agree, this shouldn't be in the core of ImageSegment but in other place. But anyway, I don't see a reason why this should be done. I vote for remove it. > remove it. I think this was added years back by Diego to make sure that truetype fonts would not lose the formatting.... seems to me that some change made truetype font morphs have a reference from the outside so that the imagesegment would not serialize them correctly, and this was the a fix to fix in when loading. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 29, 2010

[Pharo-project] Cycle dependency between ImageSegment and Multilingual

by Mariano Martinez Peck

Hi folks. Jannik pointed to me a cycle dependency between ImageSegment and Multilingual. When you create a segment, there is a way to export the complete segment (segment in itself but also the outpointers) to a file, using SmartRefStream (ImageSegment >> writeForExportOn: ) Now...you can load the that file in another image. When this is done, SmartRefStream calls the method comeFullyUpOnReload: So.... in ImageSegment >> comeFullyUpOnReload: we a bigggggg method, which this lines (a part, of course): importedObject is just one of all the objects that are in the SmartRefStream. (importedObject isKindOf: TTCFontSet) ifTrue: [ existing := TTCFontSet familyName: importedObject familyName pointSize: importedObject pointSize. "supplies default" existing == importedObject ifFalse: [importedObject becomeForward: existing]. ]. Does someone know why this piece of code should be necessary ? Of course, and I guess all agree, this shouldn't be in the core of ImageSegment but in other place. But anyway, I don't see a reason why this should be done. I vote for remove it. I remember John saying something about the menus or fonts...but I am not sure. What do you think ? Mariano

Jan. 29, 2010

Re: [Pharo-project] video in Pharo

by Hilaire Fernandes

I remember about the development of a Gstreamer plugin in 2008. Don't know its status now. Hilaire laurent laffont a Ã©crit : > Hi, > > Is it possible to play a video in Pharo ? How ? I'm thinking about > writing a Pharo interface to Pharocasts, maybe integrated to ProfStef. > It can be funny. > > Laurent > > > ------------------------------------------------------------------------ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 29, 2010

[Pharo-project] PluggableTreeMorph sends nil to setSelectedSelector callback

by Danny Chan

Hi! I found out that when you have a PluggableTreeMorph and click on an item twice, the item is deselected and the callback registered with setSelectedSelector: receives nil. This is somehow not intuitive for me, and it is also not documented. Can we change this? Danny

Jan. 29, 2010

Re: [Pharo-project] Fun with ProfStef

by Mariano Martinez Peck

On Fri, Jan 29, 2010 at 3:33 PM, Danny Chan <chan_dhf(a)yahoo.de> wrote: > Hi! > > As discussed I've added a new repository ProfStefBrowser and uploaded a > version which builds on top of the current ProfStef version from Laurent > without touching the code in the ProfStef package. > > Cool. Just be aware that you don't need to create a separete repository for that. You can have more than 1 package in a repository. Then, you can have the ProStef repository, where inside you have different packages like ProfStef core (Laurent) and ProfStefBrowser. This is easier because you have all together in the same repository. > > - I found a little bug in the UI. If you double click on a lesson, a > > debugger comes. Can you reproduce it ? > > I think I found out why this happens. Apparently, when you double click on > an > item, the item is deselected. The callback that is called in this case > receives as the item which was clicked nil. I added a workaround, but since > the callback is set using a message 'setSelectedSelector:' I personally > feel > that this behaviour is not intuitive and that this callback shouldn't be > called at all when deselecting items. Who are the guys to talk to for this > behaviour? > > If I were you, I would said a separate email you a correct subject, and people will help. There are too much traffic in this list, that not all the people can read all mails of all threads. Cheers Mariano > Danny >

Jan. 29, 2010

Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?

by Marcus Denker

On Jan 29, 2010, at 3:20 PM, Schwab,Wilhelm K wrote: > I for one never said we should throw out the new network code. But, we've been living in collective denial trying to reduce it to one defect when it is actually more complicated than that. > > Having cited the over-use of inheritance of the Squeak image as a source of various problems, I will add that inheritance *should* be used in NetNameResolver - specifically, we should group the ipv4 and ipv6 primitive sends into protocol-specific subclasses. Errors that are now weird-looking primitive failures will suddenly become DNU errors with an obvious cause. > > We should further send SocketAddress to its reward and make any required changes to use an aspect-based address that can lazily help with name resolution, and does not drag the port number into the address. The socket primitives will have to change at the same time (I think). > > IMHO, the only quick fix is to go back to known working network code, at which point we can plan for IPv6 in a future milestone. I urge the next attempt be based on an improved design, hopefully one that will allow OpenSSL sockets along with the usual suspects. I vote for exploring if libevent would be a possibility.... this is the library that the TOR project did for their strange needs, it seems it was picked up by google for Chromium and Memcached. http://google-opensource.blogspot.com/2010/01/libevent-20x-like-libevent-14… Libevent 2.0.x is the new version of Libevent from the Tor Project. Libevent is a software library whose purpose is to provide consistent fast interfaces to various operating systems' mutually incompatible fast networking facilities. No idea if it's useful as the base-layer of a new networking stack, but at least worth a look. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 29, 2010