Re: [Pharo-project] video in Pharo
true I remember the point made by david about the effort required by the port. Stef On Jan 28, 2010, at 10:54 PM, John M McIntosh wrote: On 2010-01-28, at 1:21 PM, Stéphane Ducasse wrote: there was a mpeg plugin in squeak but I do not know its status. Stef That won't be offered in the 64bit variations of squeak -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [Seaside] [ANN] seasidehosting.st for Pharo
Thanks a lot :) ! On Jan 29, 2010, at 8:50 AM, Adrian Lienhard wrote: Hi all, I'm happy to announce that seasidehosting.st now supports Pharo! There are no special settings or configurations needed. Get a Pharo/Seaside image, for instance from www.seaside.st/download/pharo, install your application, and upload it to seasidehosting.st. Before, Pharo was not supported because the special VM used did not run closure images. Since many people asked for support of Pharo, we updated the VM now. It took some time, but as promised, we managed to finish it before the upcoming Pharo 1.0 release. I'd like to thank ESUG and netstyle.ch for their continuous support of Seasidehosting! Cheers, Adrian ___ http://www.adrian-lienhard.ch/ ___ seaside mailing list seas...@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] video in Pharo
On Jan 29, 2010, at 9:14 AM, Stéphane Ducasse wrote: true I remember the point made by david about the effort required by the port. And what do you want with an old mpeg decoder anyway? The world moved on the last 10 years... Marcus Stef On Jan 28, 2010, at 10:54 PM, John M McIntosh wrote: On 2010-01-28, at 1:21 PM, Stéphane Ducasse wrote: there was a mpeg plugin in squeak but I do not know its status. Stef That won't be offered in the 64bit variations of squeak -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] video in Pharo
yes marcus don't be negative we do pharo to think about the future. :) true I remember the point made by david about the effort required by the port. And what do you want with an old mpeg decoder anyway? The world moved on the last 10 years... Marcus Stef On Jan 28, 2010, at 10:54 PM, John M McIntosh wrote: On 2010-01-28, at 1:21 PM, Stéphane Ducasse wrote: there was a mpeg plugin in squeak but I do not know its status. Stef That won't be offered in the 64bit variations of squeak -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?
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? Cheers, Adrian On Jan 28, 2010, at 22:52 , John M McIntosh wrote: Some of this is all related to http://bugs.squeak.org/view.php?id=7392 However there is no expectations than any unix socket support code fixes will be forthcoming this year, or next? On 2010-01-28, at 8:50 AM, Stéphane Ducasse wrote: +1 -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?
+10. -Original Message- From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Friday, January 29, 2010 7:09 AM To: Pharo-project Development Subject: Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508? 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? Cheers, Adrian On Jan 28, 2010, at 22:52 , John M McIntosh wrote: Some of this is all related to http://bugs.squeak.org/view.php?id=7392 However there is no expectations than any unix socket support code fixes will be forthcoming this year, or next? On 2010-01-28, at 8:50 AM, Stéphane Ducasse wrote: +1 -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com == = ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?
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. Bill -Original Message- From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Michael Rueger Sent: Friday, January 29, 2010 7:23 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508? 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fun with ProfStef
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. - 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? Danny ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fun with ProfStef
On Fri, Jan 29, 2010 at 3:33 PM, Danny Chan chan_...@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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] PluggableTreeMorph sends nil to setSelectedSelector callback
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Cycle dependency between ImageSegment and Multilingual
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 bigg 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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Cycle dependency between ImageSegment and Multilingual
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 bigg 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. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Fwd: [Esug-list] 2 young Smalltalk developers for Germany
Ok...it is not Pharo, but it is Smalltalk ! -- Forwarded message -- From: Nowak, Helge hno...@cincom.com Date: Fri, Jan 29, 2010 at 5:37 PM Subject: [Esug-list] 2 young Smalltalk developers for Germany To: esug-l...@lists.esug.org, v...@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:hno...@cincom.com hno...@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-l...@lists.esug.org http://lists.esug.org/listinfo/esug-list ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] video in Pharo
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 john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] video in Pharo
John M McIntosh a écrit : I did the GStreamer plugin for Etoys ala OLPC Ah right! 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. Just curious as I don't have time now to look deeply on that: Is it available as an external package one can load in a Pharo image? Does it requiere VM magics? Hilaire ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] video in Pharo
Just curious as I don't have time now to look deeply on that: Is it available as an external package one can load in a Pharo image? Does it requiere VM magics? Hilaire Well I'm not sure what you are asking for. The Gstreamer stuff starts at: MCHttpRepository location: 'http://www.squeaksource.com/GStreamer' user: '' password: '' You need a plugin and the GStreamer underpinnings install in your operating system. If you have have a linux box that is easy. If you have a mac, you could use MacPorts to install GStreamer and I could give you a plugin I built for test purposes. As for the Sophie stuff, well it uses FFI for talking to Quicktime, there is an optional quicktime plugin but all that is used for is to let quicktime tell us when it has rendered a frame into a squeak surface so we can signal a squeak semaphore to draw the surface to the Display. The fall back is to do a fixed frame rate drawing cycle, which is what happens on Windows. The Sophie player of course uses Tweak as a reference base, but could be converted to some other UI framework. === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Coordination :)
I like the idea that any contributions is worth :) http://www.ted.com/talks/lang/eng/clay_shirky_on_institutions_versus_collaboration.html Ted talk. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Coordination :)
great video Laurent On Fri, Jan 29, 2010 at 8:58 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: I like the idea that any contributions is worth :) http://www.ted.com/talks/lang/eng/clay_shirky_on_institutions_versus_collaboration.html Ted talk. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fun with ProfStef
On Fri, Jan 29, 2010 at 6:49 PM, Danny Chan chan_...@yahoo.de wrote: Am Freitag, 29. Januar 2010 15:38:58 schrieb Mariano Martinez Peck: On Fri, Jan 29, 2010 at 3:33 PM, Danny Chan chan_...@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. Ah, understand. I was confused by packages vs repositories. I will copy the packages to the ProfStef repository. Danny Welcome ProfStef-Core and ProfStef-Tests ! Laurent ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Coordination :)
great video Yes I like the fact that the one issue single committers are still really important And this is why we pay attention to any improvements :) BTW laureant with 1.1 you do not need the isKindOf: in the browser anymore :) Laurent On Fri, Jan 29, 2010 at 8:58 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: I like the idea that any contributions is worth :) http://www.ted.com/talks/lang/eng/clay_shirky_on_institutions_versus_collaboration.html Ted talk. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Coordination :)
BTW laureant with 1.1 you do not need the isKindOf: in the browser anymore :) OK... I will try 1.1 when 1.0 will be released :) I think I should do less (different) stuff time .. time ... time ... Laurent Laurent On Fri, Jan 29, 2010 at 8:58 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: I like the idea that any contributions is worth :) http://www.ted.com/talks/lang/eng/clay_shirky_on_institutions_versus_collaboration.html Ted talk. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.1] #11185 and 1186
[update 1.1] #11185 11186 - Issue 1880: nextChunk speedup part one and part two Thanks a lot henrik Stef PS: Miguel I did not check yet your fix because I wanted to do something relaxing to recharge my battery :) ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] ToolBuilder improvements....
Hi guys to relax I spent some time and I checked all the Toolbuilder-Kernel, ToolBuilder-Morphic changes in Squeak. Most of them looks good so I produced a slice. Slice-1895 Issue 1895: ToolBuilder squeak integration and related If one of you want to have a look go ahead and let me know. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] about: Slice-CleaningAndFixingImageSegmentPart2-MarianoMartinezPeck.9
hi M should I integrate that? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about: Slice-CleaningAndFixingImageSegmentPart2-MarianoMartinezPeck.9
On Fri, Jan 29, 2010 at 9:33 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: hi M that's TOO lazy :) should I integrate that? Yes. It was the last merge we reviewed together at Douai. Do you remeber ? That you discovered a little problem I was introducing :) and then I fixed it. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Pharo web documentation viewer
Hi, now that seasidehosting can run Pharo, I've uploaded rc2 image with SimpleWebDoc. All packages documentation browsable here: http://magaloma.seasidehosting.st Laurent ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] peek and friends
hi Igor finally should I integrate http://bugs.squeak.org/view.php?id=7446 ? I was waiting because you said you were confused Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?
The changed you suggested worked on my machine, mac os X and also on a Debian. Hernan. 2010/1/28 Miguel Enrique Cobá Martinez miguel.c...@gmail.com El jue, 28-01-2010 a las 07:57 -0500, Schwab,Wilhelm K escribió: I think you are correct about that being a bad change, but there is more wrong than just that. There are IPv6-specific calls that are not protected by subsequent tests on #useOldNetwork. Further, the IPv6 code does not work correctly, so many of us appear to need to override #useOldNetwork to always return true. I make that change in #useOldNetwork rather than #initialize. Bill Yes, I know that the code is very difficult to understand, mainly because of the primitives. They brake the understanding you have so far when you have to switch to c code with a lot of pointers/structs/string buffers. The problem here is that, now it is impossible to change the networks subsystem of Pharo (or squeak). As Mariano said, we *need* to release 1.0 and this bug can be a show stopper. Also, with due respect to the original coders of the network subsystem, the code is really convoluted (I know that networking isn't simple), at least to understand the fully implication of a simple change like this. It is not a well factored code. It mixes GUI prompts, IPv4, IPv6, primitives and smalltalk code. So I think that is difficult to have someone with the enough knowledge to change the code so that it works for now. But that is how things are now. Maybe our own ignorance of the code is what negates us a fix, but we need to left that apart and work a solution for the *particular* problem in hand. For 1.1 we can discuss new implementation if that is required. As Adrian said, there are users that need useOldNetwork true and some others that need useOldNetwork to false. The problem is that we don't fully understand the consequences of both changes. So, people, we need your help. Those who are most familiar with the network code, please, please, take a look and suggest a solution for the 1.0 release. *No* full rewrites, no throw code, no blaming, just a working workaround for this. Regards Miguel Coba -- Miguel Cobá http://miguel.leugim.com.mx ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?
The OS/vm is part of it; behavior also depends on whether the network is configured for ipv6, and perhaps whether or not it is done correctly. It gets complicated in a hurry. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Hernan Wilkinson [hernan.wilkin...@gmail.com] Sent: Friday, January 29, 2010 5:27 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508? The changed you suggested worked on my machine, mac os X and also on a Debian. Hernan. 2010/1/28 Miguel Enrique Cobá Martinez miguel.c...@gmail.commailto:miguel.c...@gmail.com El jue, 28-01-2010 a las 07:57 -0500, Schwab,Wilhelm K escribió: I think you are correct about that being a bad change, but there is more wrong than just that. There are IPv6-specific calls that are not protected by subsequent tests on #useOldNetwork. Further, the IPv6 code does not work correctly, so many of us appear to need to override #useOldNetwork to always return true. I make that change in #useOldNetwork rather than #initialize. Bill Yes, I know that the code is very difficult to understand, mainly because of the primitives. They brake the understanding you have so far when you have to switch to c code with a lot of pointers/structs/string buffers. The problem here is that, now it is impossible to change the networks subsystem of Pharo (or squeak). As Mariano said, we *need* to release 1.0 and this bug can be a show stopper. Also, with due respect to the original coders of the network subsystem, the code is really convoluted (I know that networking isn't simple), at least to understand the fully implication of a simple change like this. It is not a well factored code. It mixes GUI prompts, IPv4, IPv6, primitives and smalltalk code. So I think that is difficult to have someone with the enough knowledge to change the code so that it works for now. But that is how things are now. Maybe our own ignorance of the code is what negates us a fix, but we need to left that apart and work a solution for the *particular* problem in hand. For 1.1 we can discuss new implementation if that is required. As Adrian said, there are users that need useOldNetwork true and some others that need useOldNetwork to false. The problem is that we don't fully understand the consequences of both changes. So, people, we need your help. Those who are most familiar with the network code, please, please, take a look and suggest a solution for the 1.0 release. *No* full rewrites, no throw code, no blaming, just a working workaround for this. Regards Miguel Coba -- Miguel Cobá http://miguel.leugim.com.mx ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.frmailto:Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Bug in NetNameResolver on PharoCore 10508?
El vie, 29-01-2010 a las 19:27 -0300, Hernan Wilkinson escribió: The changed you suggested worked on my machine, mac os X and also on a Debian. Thank you for testing. I have only a Debian Squeeze machine and only tested there. But is good to know that works also in MacOS X. I am installing Windows 7 inside virtualbox to test in windows. Cheers Hernan. 2010/1/28 Miguel Enrique Cobá Martinez miguel.c...@gmail.com El jue, 28-01-2010 a las 07:57 -0500, Schwab,Wilhelm K escribió: I think you are correct about that being a bad change, but there is more wrong than just that. There are IPv6-specific calls that are not protected by subsequent tests on #useOldNetwork. Further, the IPv6 code does not work correctly, so many of us appear to need to override #useOldNetwork to always return true. I make that change in #useOldNetwork rather than #initialize. Bill Yes, I know that the code is very difficult to understand, mainly because of the primitives. They brake the understanding you have so far when you have to switch to c code with a lot of pointers/structs/string buffers. The problem here is that, now it is impossible to change the networks subsystem of Pharo (or squeak). As Mariano said, we *need* to release 1.0 and this bug can be a show stopper. Also, with due respect to the original coders of the network subsystem, the code is really convoluted (I know that networking isn't simple), at least to understand the fully implication of a simple change like this. It is not a well factored code. It mixes GUI prompts, IPv4, IPv6, primitives and smalltalk code. So I think that is difficult to have someone with the enough knowledge to change the code so that it works for now. But that is how things are now. Maybe our own ignorance of the code is what negates us a fix, but we need to left that apart and work a solution for the *particular* problem in hand. For 1.1 we can discuss new implementation if that is required. As Adrian said, there are users that need useOldNetwork true and some others that need useOldNetwork to false. The problem is that we don't fully understand the consequences of both changes. So, people, we need your help. Those who are most familiar with the network code, please, please, take a look and suggest a solution for the 1.0 release. *No* full rewrites, no throw code, no blaming, just a working workaround for this. Regards Miguel Coba -- Miguel Cobá http://miguel.leugim.com.mx ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel Cobá http://miguel.leugim.com.mx ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
