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

Re: [Pharo-project] Fwd: About SPDF

by StÃ©phane Ducasse

+1 Stef On Aug 29, 2010, at 6:22 PM, Miguel Enrique CobÃ¡ MartÃnez wrote: > El sÃ¡b, 28-08-2010 a las 20:31 +0200, Christian Haider escribiÃ³: >> I dont think that this is so easy. >> >> My product smallCharts uses the PDF implementation as its primary vector graphics output format - I rely on it. >> >> What I want is to make the implementation of the spec available to the community. And I would like others to use it and maybe contribute to some of the many uncovered areas of the spec (pixmaps, encryption to name a few). >> >> But I dont want to lose control. > > This is always a risk in any true open source software. Of course there > are ways to avoid losing control even with very permissive licenses like > MIT, like hearing your contributors, your porters, etc. That way the > need to do a fork is minimized. If you discard good code for bad reasons > you're most surely betting for a fork. > Now, you can work only in VisualWorks, and some people can port (that is > not the same as fork) to other platforms. In the way they can send you > patches that make the original upstream version less platform dependent > so that the porting is easier with time to new platforms, this is good > for the project because can reach more platforms if it is really open in > the development and contribution process. > >> I dont like several incompatible development streams for different dialects. And I would like to integrate contributions myself. >> > > This don't need to happen, there are libraries (Sport, Grease) that put > a layer between platform specifics and your code so that is easier for > maintainers of the different ports to stay compatible. But again, the > principal reason of forking is contribution process issues and not > platform specific issues. > >> One way to do this is to have the primary implementation in VisualWorks and a reliable, not too intrusive way of exporting it to other dialects. If such an export mechanism would be available, I could do that. But I dont have time to develop one. >> > > I think that this will be solved when the actual problem arrives. Don't > worry about this right now. Just put a working version for VW and > someone (I for sure) will step forward to contribute the porting to > pharo. > >> Any thoughts about such a procedure? > > > Finally, as the community is involved, more and more features that you > haven't had time to do will be done. A big project begins with a little > project. > > Cheers > >> >> Christian >> >>> -----UrsprÃ¼ngliche Nachricht----- >>> Von: pharo-project-bounces(a)lists.gforge.inria.fr >>> [mailto:pharo-project-bounces@lists.gforge.inria.fr] Im >>> Auftrag von Miguel Enrique CobÃ¡ MartÃnez >>> Gesendet: Samstag, 28. August 2010 19:31 >>> An: Pharo-project(a)lists.gforge.inria.fr >>> Betreff: Re: [Pharo-project] Fwd: About SPDF >>> >>> El sÃ¡b, 28-08-2010 a las 18:42 +0200, Christian Haider escribiÃ³: >>>> I have a Smalltalk only (with help of zlib) implementation >>> of PDF (1.7) in VisualWorks. >>>> >>>> I'd love to have a port for Pharo but not the time to do it... >>>> >>>> I thought of releasing it as open source. >>> >>> Please do it, and with MIT license would be perfect because it will >>> avoid a lot of problems in the future. >>> >>> Either publish it as a file out in your page or in a mail, or create a >>> project in squeaksource with read or read/write access for >>> everyone and >>> someone will jump and will work out the porting to pharo. >>> >>> The main thing is to let the code out as MIT and then >>> everything will be >>> easy. >>> >>> Thanks >>> >>>> >>>> Ideas? Need? >>>> >>>> Cheers, >>>> Christian >>>> >>>>> -----UrsprÃ¼ngliche Nachricht----- >>>>> Von: pharo-project-bounces(a)lists.gforge.inria.fr >>>>> [mailto:pharo-project-bounces@lists.gforge.inria.fr] Im >>>>> Auftrag von Torsten Bergmann >>>>> Gesendet: Mittwoch, 25. August 2010 08:31 >>>>> An: pharo-project(a)lists.gforge.inria.fr >>>>> Betreff: [Pharo-project] Fwd: About SPDF >>>>> >>>>>> Hehe, too much legal terms to me.....What we could do? >>> Can modify, >>>>>> create a new package, etc? >>>>> >>>>> The license of SPDF was not open enough for me in the past - thats >>>>> why I created the binding to the Haru PDF Library: >>>>> >>>>> http://www.squeaksource.com/HPDF.html >>>>> http://libharu.sourceforge.net >>>>> >>>>> This requires FFI and an external shared library. >>>>> >>>>> If you want to have a Smalltalk only solution I think >>>>> you have to digg in the PDF spec and write an own. Assumed >>>>> you have lots of time to spend on bits and bytes and >>>>> writing nice unit tests for PDF streams. >>>>> >>>>> Similar to iText for Java, this allows you change the >>>>> license and block your government later ;), see the story >>>>> of Bruno Lowagie [1] >>>>> >>>>> There are also other PDF alternatives beside HPDF and >>> SPDF (see [2]) >>>>> >>>>> Bye >>>>> Torsten >>>>> >>>>> >>>>> [1] >>>>> http://techcrunch.com/2009/05/20/open-source-developer-intends >>>>> -to-block-belgian-government-from-using-his-technology-over-ta >>>> x-dispute/ >>>>> [2] http://www.seaside.st/documentation/pdfs >>>>> >>>>> >>>>> >>>>> -- >>>>> GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! >>>>> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)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(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 29, 2010

Re: [Pharo-project] Poll: missing libraries to support business

by stephane ducasse

Thanks for your list. Now my comments. Did you guess why I asked this pol? - How can companies expect that all these points will be done if nobody puts money on the table or allocate time of their employee, or open source some of their software? Magic, wishful thinking? - We will do what we can and what is in our critical path. - We are thinking a consortium of companies and institutions that could be willing to help pharo. Now so far I do not see companies really putting effort so may be nothing will happen but this will not be because of us. :) > High Priority: > Enusure very high reliability of the base Pharo. No bugs that are not fixable by the average developer with a bit of google and sending a few emails. If it needs that one expert in one other end.. business continuity is hugely impacted - INRIA is putting 24 months expert engineer on the table and we will clean and simplify the core. Now we will see what will happen. > Primary: > * better-faster VM aka Cog mainstream Teleplace played it the perfect way. I think that they will gain from the help of the community but so far I imagine that they pay every month the salary of people to develop and maintain Cog so again no real magic. > * Highly performant DBMS connectivity natively akin to JDBC through to all DBs no DB specific stuff like now, the Squeak DBX is not business friendly > * Comprehensive Web Services + XMLRPC there is a XMLRPC package that cries to get improved. Just allocate some time and improve it. > * Pharo-Groovy bridge and / or Pharo-Ruby bridge ( or can we make Pharo work in tandem with a JVM..! this will help leverage the tons of frameworks in existence even if they are tad slower than native Java) There is javaconnect and JNI and I imagine that people are welcomed to help and improve. > * Configuration Management System plugin for SVN > * Acceleration of easy docs and plugins/ web development related framework interfaces from Seaside viz flex/ silverlight: many that are possible as of now, but needs a Smalltalk expert to cobble it up did you discuss that in the seaside mailing-list > * Have not really gone deeper with Webclient/ FTPClient/ SMTPClient et als. they need to be really simple/ highly reliable/ dumbed down for the average coder to pick snippets and make it work Yes > May be lots more.. I can bring in lot more thought this in terms of Generic/ Sectoral or Domain/ Type of Apps preferences viz: Banking/Insurance/Utilities/Technical/ Web vs GUI etc ...So first we should think hard on the segment you want to hit harder.. > > Secondary: > * Better tools for GUI Dev and more standard GUI development capabilities yes but again... > * Make Pharo easily usable for a team of 100+ developers together in one/multiple locations with code synch issues, change / version control , performance ( a host of other stuff included) taken care of. There is Monticello. ***we*** are working on a fast binary loader but but but nothing is clear. > * Pluggable to industry standard tools for development: Rational/ Together Soft viz for UML creation and conversion to code / reverse engineer code to UML why would I spent my time without support to connect with tools that cost thousands dollars a license? > Follow through with: > * Pluggable with QTP/ Testing Automation tools.. Actually this is very important in the standard large volume development. Makes a huge difference for the risk mitigation for the company. really inexpensive , kind of not so highly technical staff runs this show in comparison to Unit Tests/ test automation through ST code is a more riskier investment and I have not seen in JAva/ .Net / or even Smalltalk large legacy projects unit test done and maintained well enough It seems that pharo is the first smalltalk to have a good integration with hudson (thanks guys we know who you are) so there is definitively some good news on that item. > > > -Skrish > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 29, 2010

Re: [Pharo-project] [squeak-dev] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.

by Tudor Girba

Hi, On 29 Aug 2010, at 19:44, John M McIntosh wrote: > Ah, yes this is a functional change between 10.5 and 10.6 > > Can you document a test case for me in a 4.x squeak VM so I can > figure out what to do for the 10.5 users How exactly should I do that? I just checked in a 4.2.2 and everything works as expected. Cheers, Doru > > On 2010-08-29, at 10:37 AM, Tudor Girba wrote: > >> On 4.2.2beta1 these keys work as expected. >> >> I have to mention that I am still on Mac OS X 10.5.8. Perhaps the >> others are on Snow Leopard. Could that be a difference? >> >> Cheers, >> Doru > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > -- www.tudorgirba.com "Speaking louder won't make the point worthier."

Aug. 29, 2010

Re: [Pharo-project] [squeak-dev] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.

by John M McIntosh

Ah, yes this is a functional change between 10.5 and 10.6 Can you document a test case for me in a 4.x squeak VM so I can figure out what to do for the 10.5 users On 2010-08-29, at 10:37 AM, Tudor Girba wrote: > On 4.2.2beta1 these keys work as expected. > > I have to mention that I am still on Mac OS X 10.5.8. Perhaps the others are on Snow Leopard. Could that be a difference? > > Cheers, > Doru -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Aug. 29, 2010

Re: [Pharo-project] [squeak-dev] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.

by Tudor Girba

On 4.2.2beta1 these keys work as expected. I have to mention that I am still on Mac OS X 10.5.8. Perhaps the others are on Snow Leopard. Could that be a difference? Cheers, Doru On 29 Aug 2010, at 19:27, John M McIntosh wrote: > Ok, so I have Ken Brown & Mariano Martinez Peck saying the cntl- > arrow keys work, and Tudor Girba saying they don't work. > Obviously I need someone to document the behaviour in a 4.x VM and > then in 5.8b4 so we understand what happens or doesn't happen. > > > On 2010-08-29, at 7:45 AM, Ken G. Brown wrote: > >> ... >> When Squeak has focus, cntl-arrow keys change Spaces as is normal >> on MacPro 10.6.4 >> >> Ken G. Brown >> > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Be rather willing to give than demanding to get."

Aug. 29, 2010

Re: [Pharo-project] [squeak-dev] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.

by John M McIntosh

On 2010-08-29, at 4:57 AM, Tudor Girba wrote: > What are the implications of these optimizations? By the sound of it they should influence the rendering. Is that correct? Are there any tests we could do to see the improvements? You can use the frame rate morphic to observe the rate rate you get in your application, compare to 4.x. Comparing to a 5.7 in 64bit mode may not be fair because with the same open/GL code it does a frame rate 25% better. I'm also interested in any drawing issues, yes it does lose it's mind when you resize the window (I might fix that someday), but I'm more concerned about drawing artifacts & visual differences between it now and 4.x -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Aug. 29, 2010

Re: [Pharo-project] [squeak-dev] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.

by John M McIntosh

Ok, so I have Ken Brown & Mariano Martinez Peck saying the cntl-arrow keys work, and Tudor Girba saying they don't work. Obviously I need someone to document the behaviour in a 4.x VM and then in 5.8b4 so we understand what happens or doesn't happen. On 2010-08-29, at 7:45 AM, Ken G. Brown wrote: > ... > When Squeak has focus, cntl-arrow keys change Spaces as is normal on MacPro 10.6.4 > > Ken G. Brown > -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Aug. 29, 2010

Re: [Pharo-project] OSProcess - can it pipe 1 MB?

by David T. Lewis

On Sun, Aug 29, 2010 at 11:36:02AM -0400, Schwab,Wilhelm K wrote: > I am trying to pipe roughly 1 MB of data into a program on Linux; I know it can handle the load, because I have tested it with by cat-ing a script and the data. I do not yet promise that my Pharo code is correct; if the program did not respond or returned junk, I would look to myself. But I am getting errors suggesting that AttachableFileStream is failing on writing to the pipe, and it's very suspicious that it simply can't handle the size of the string. Any ideas? > > Bill Try googling "maximum size of write to linux pipe". Unix pipes have a capacity limit, and the write will fail if you try to write too large a chunk all at once. Dave

Aug. 29, 2010

Re: [Pharo-project] Fwd: About SPDF

by Miguel Enrique CobÃ¡ MartÃnez

El sÃ¡b, 28-08-2010 a las 20:31 +0200, Christian Haider escribiÃ³: > I dont think that this is so easy. > > My product smallCharts uses the PDF implementation as its primary vector graphics output format - I rely on it. > > What I want is to make the implementation of the spec available to the community. And I would like others to use it and maybe contribute to some of the many uncovered areas of the spec (pixmaps, encryption to name a few). > > But I dont want to lose control. This is always a risk in any true open source software. Of course there are ways to avoid losing control even with very permissive licenses like MIT, like hearing your contributors, your porters, etc. That way the need to do a fork is minimized. If you discard good code for bad reasons you're most surely betting for a fork. Now, you can work only in VisualWorks, and some people can port (that is not the same as fork) to other platforms. In the way they can send you patches that make the original upstream version less platform dependent so that the porting is easier with time to new platforms, this is good for the project because can reach more platforms if it is really open in the development and contribution process. > I dont like several incompatible development streams for different dialects. And I would like to integrate contributions myself. > This don't need to happen, there are libraries (Sport, Grease) that put a layer between platform specifics and your code so that is easier for maintainers of the different ports to stay compatible. But again, the principal reason of forking is contribution process issues and not platform specific issues. > One way to do this is to have the primary implementation in VisualWorks and a reliable, not too intrusive way of exporting it to other dialects. If such an export mechanism would be available, I could do that. But I dont have time to develop one. > I think that this will be solved when the actual problem arrives. Don't worry about this right now. Just put a working version for VW and someone (I for sure) will step forward to contribute the porting to pharo. > Any thoughts about such a procedure? Finally, as the community is involved, more and more features that you haven't had time to do will be done. A big project begins with a little project. Cheers > > Christian > > > -----UrsprÃ¼ngliche Nachricht----- > > Von: pharo-project-bounces(a)lists.gforge.inria.fr > > [mailto:pharo-project-bounces@lists.gforge.inria.fr] Im > > Auftrag von Miguel Enrique CobÃ¡ MartÃnez > > Gesendet: Samstag, 28. August 2010 19:31 > > An: Pharo-project(a)lists.gforge.inria.fr > > Betreff: Re: [Pharo-project] Fwd: About SPDF > > > > El sÃ¡b, 28-08-2010 a las 18:42 +0200, Christian Haider escribiÃ³: > > > I have a Smalltalk only (with help of zlib) implementation > > of PDF (1.7) in VisualWorks. > > > > > > I'd love to have a port for Pharo but not the time to do it... > > > > > > I thought of releasing it as open source. > > > > Please do it, and with MIT license would be perfect because it will > > avoid a lot of problems in the future. > > > > Either publish it as a file out in your page or in a mail, or create a > > project in squeaksource with read or read/write access for > > everyone and > > someone will jump and will work out the porting to pharo. > > > > The main thing is to let the code out as MIT and then > > everything will be > > easy. > > > > Thanks > > > > > > > > Ideas? Need? > > > > > > Cheers, > > > Christian > > > > > > > -----UrsprÃ¼ngliche Nachricht----- > > > > Von: pharo-project-bounces(a)lists.gforge.inria.fr > > > > [mailto:pharo-project-bounces@lists.gforge.inria.fr] Im > > > > Auftrag von Torsten Bergmann > > > > Gesendet: Mittwoch, 25. August 2010 08:31 > > > > An: pharo-project(a)lists.gforge.inria.fr > > > > Betreff: [Pharo-project] Fwd: About SPDF > > > > > > > > >Hehe, too much legal terms to me.....What we could do? > > Can modify, > > > > >create a new package, etc? > > > > > > > > The license of SPDF was not open enough for me in the past - thats > > > > why I created the binding to the Haru PDF Library: > > > > > > > > http://www.squeaksource.com/HPDF.html > > > > http://libharu.sourceforge.net > > > > > > > > This requires FFI and an external shared library. > > > > > > > > If you want to have a Smalltalk only solution I think > > > > you have to digg in the PDF spec and write an own. Assumed > > > > you have lots of time to spend on bits and bytes and > > > > writing nice unit tests for PDF streams. > > > > > > > > Similar to iText for Java, this allows you change the > > > > license and block your government later ;), see the story > > > > of Bruno Lowagie [1] > > > > > > > > There are also other PDF alternatives beside HPDF and > > SPDF (see [2]) > > > > > > > > Bye > > > > Torsten > > > > > > > > > > > > [1] > > > > http://techcrunch.com/2009/05/20/open-source-developer-intends > > > > -to-block-belgian-government-from-using-his-technology-over-ta > > > x-dispute/ > > > > [2] http://www.seaside.st/documentation/pdfs > > > > > > > > > > > > > > > > -- > > > > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > > > > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > > > > > > > _______________________________________________ > > > > Pharo-project mailing list > > > > Pharo-project(a)lists.gforge.inria.fr > > > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)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(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Aug. 29, 2010

Re: [Pharo-project] OmniBrowser chapter for PBE 2 is now available

by StÃ©phane Ducasse

thanks lukas On Aug 29, 2010, at 11:29 AM, Lukas Renggli wrote: > Some comments: > > - The term "Widget" is not used in the architecture of the OB > framework anywhere. Maybe it would be better to replace it with the > term "Panel" that is used in the framework. > > - Figure 1.1 depicts a bug of the un-themed scroll-bar that has been > fixed a long time ago when Polymorph was introduced. > > - p. 9 at the bottom there is a comma disconnected from the previous word. > > - p. 12 "This enables a smooth gathering of independently realized > commands." -> "..., and allows one to cleanly extend existing browsers > without having to patch the system (e.g. refactoring browser)." > > - p. 13 The definition has nothing to do with editable text. By > overriding the right methods in the OBNode a node is directly editable > as well. The reason to have a separate OBDefintion is only to be able > have multiple different definitions for a single node (e.g. to provide > different views on source code from an OBMethodNode: source code, byte > code, decompiled code, pretty-printed code). > > - p. 14 "Each of this method should return the class of the command > (and not an instance of it)." This is not true. The requirement is > that the returned object responds to #on:for:. There are examples > where factory objects or OBCommand instances are returned. > > - p. 15 "These actions enable interaction with the domain model, > however they do not allow further navigation in the metagraph." This > is not true. There are various ways to navigate and update the > metagraph, e.g. aNode signalSelection (see p.20 "Widget > notification"). > > - Figure 1.5 does depict O2, not the "OmniBrowser System Browser" that > is described in the text in Section 1.4. > > - p. 24: The acknowledgements fit to O2, but they seem distorted in > the context of OmniBrowser. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 29, 2010