- Pharo-dev - lists.pharo.org

Re: [Pharo-project] About ConfigurationOfXMLSupport

by Norbert Hartl

Am 06.01.2012 um 14:13 schrieb StÃ©phane Ducasse: >> >> I disagree. There is more than one way to create a mess. One is what you describe! The other one you get by over-engineering things. If you create a configuration for every package that consist of one file only you will get tons of configuration files with hard to maintain dependencies. A bigger mess in my opinion (and experience). You always have to leverage the use and effect of doing things. Configurations can have groups which is an internal separation of things that belong together. >> As there are more ways to do it I have trouble understanding the "if each package move its clients...". There is no need to have a single approach. If it would be that way it would be good if pharo would just follow ANSI. > > So then why not having a single one? You don't need to prove you are stubborn sometimes. I know it :) > I do not use Sixx. > But I use XMLParser. > > So do you think that I can maintain pastel, sixx versions that I do not use? So do you think that having a large configuration > with parts that are unmaintained is good? > I do not think so. > Stef, what are you trying to tell? Of course, you can't maintain a software you do not use. Nobody tells me you maintain the software _that you_ use. But I can understand that you do not care about breaking clients of the software that you use and maintain. And so it is better to have even the smallest client in its own configuration because if it would be in eye sight you might be forced to think about to care about this package as well. Is it like that? > So I will create a ConfigurationOfXMLParser. > Yes, and create it for pharo only, so I do not need to care about it. > >>>> Sixx is a serializer/deserializer for XML and therefor is using streams. Streams are one of those fine examples where platform differences can drive you nuts. I couldn't understand all the fuzz of not using sport and preferring grease for seaside but only for seaside etc. I had a hard time dealing with platform subtleties for character encoding (yes, I care!) and streams when it comes to dialects. So I decided to introduce grease and made the GemStone port of Sixx depend on streams and character encoding behaviour of grease (Please sue me!). Dale was so kind to make even GemStone Core to depend on Grease to make Xml loadable by the core. >>> >>> But put that in ConfigurationOfSixx :) >>> >> Well, just do it. > > I do not use Sixx. > But I use XMLParser. > Believe me, nobody forces you to. > >> I personally would put xml parser, sixx, pastell, other xpath libs and the pull parser in a single configuration file. If someone likes to do XML stuff he/she will be fine to find it maintained in a single place. All of the mentioned libs are single packaged, tiny things. This would probably also help to find an existing lib before implemented your own (search for xpath in the mailing lists). >> I understand you are looking for something "clean". Well, knock yourself off. I'm more after usable units. > > No I'm looking for usable things too and when I load configurationOfXML to get the parser I'm not interested in the clients > of XMLParser, else you should also put Soup and a couple of others. > If you load ConfigurationOfXMLSupport and use it _where_ do you see what is configured in there? Maybe we should proceed this discussion in spring. I understand that in winter when the light is dim it is too easy to see the world in black and white. Not your fault! Norbert > >> >> Norbert >> >>> >>> >>>> Later I recognized that in pharo terms this is not possible. I had a discussion with Sven because I wanted to have a zinc port for gemstone. But he was more interested to get zinc close to pharo. So the grease way was not an option and the result is the port to gemstone is still incomplete and hard to maintain. >>>> >>>> Sorry for the long answer but this is just another story of how hard it is to have modular systems where all of the mentioned issues wouldn't be that much of a problem. I would wish that we find a good solution to make sources more interchangable between platforms. I don't mean get rid of the dialect differences (because I don't think it will happen) but to design code in a way that platform subtleties can be compensated in an object oriented way. >>>> >>>> Norbert >>>> >>>> >>> >>> >> >> > >

Jan. 6, 2012

Re: [Pharo-project] About ConfigurationOfXMLSupport

by StÃ©phane Ducasse

> > I disagree. There is more than one way to create a mess. One is what you describe! The other one you get by over-engineering things. If you create a configuration for every package that consist of one file only you will get tons of configuration files with hard to maintain dependencies. A bigger mess in my opinion (and experience). You always have to leverage the use and effect of doing things. Configurations can have groups which is an internal separation of things that belong together. > As there are more ways to do it I have trouble understanding the "if each package move its clients...". There is no need to have a single approach. If it would be that way it would be good if pharo would just follow ANSI. So then why not having a single one? I do not use Sixx. But I use XMLParser. So do you think that I can maintain pastel, sixx versions that I do not use? So do you think that having a large configuration with parts that are unmaintained is good? I do not think so. So I will create a ConfigurationOfXMLParser. >>> Sixx is a serializer/deserializer for XML and therefor is using streams. Streams are one of those fine examples where platform differences can drive you nuts. I couldn't understand all the fuzz of not using sport and preferring grease for seaside but only for seaside etc. I had a hard time dealing with platform subtleties for character encoding (yes, I care!) and streams when it comes to dialects. So I decided to introduce grease and made the GemStone port of Sixx depend on streams and character encoding behaviour of grease (Please sue me!). Dale was so kind to make even GemStone Core to depend on Grease to make Xml loadable by the core. >> >> But put that in ConfigurationOfSixx :) >> > Well, just do it. I do not use Sixx. But I use XMLParser. > I personally would put xml parser, sixx, pastell, other xpath libs and the pull parser in a single configuration file. If someone likes to do XML stuff he/she will be fine to find it maintained in a single place. All of the mentioned libs are single packaged, tiny things. This would probably also help to find an existing lib before implemented your own (search for xpath in the mailing lists). > I understand you are looking for something "clean". Well, knock yourself off. I'm more after usable units. No I'm looking for usable things too and when I load configurationOfXML to get the parser I'm not interested in the clients of XMLParser, else you should also put Soup and a couple of others. > > Norbert > >> >> >>> Later I recognized that in pharo terms this is not possible. I had a discussion with Sven because I wanted to have a zinc port for gemstone. But he was more interested to get zinc close to pharo. So the grease way was not an option and the result is the port to gemstone is still incomplete and hard to maintain. >>> >>> Sorry for the long answer but this is just another story of how hard it is to have modular systems where all of the mentioned issues wouldn't be that much of a problem. I would wish that we find a good solution to make sources more interchangable between platforms. I don't mean get rid of the dialect differences (because I don't think it will happen) but to design code in a way that platform subtleties can be compensated in an object oriented way. >>> >>> Norbert >>> >>> >> >> > >

Jan. 6, 2012

[Pharo-project] Bug in #pointsTo: ?

by Mariano Martinez Peck

Hi guys. Levente recommended us to integrate the new version of #pointsTo:, and I did it. But not I think I found a bug. The method is: pointsTo: anObject "Answers true if I hold a reference to anObject, or false otherwise. Or stated another way: Answers true if the garbage collector would fail to collect anObject because I hold a reference to it, or false otherwise" ^ (self instVarsInclude: anObject) or: [self class == anObject] The problem is that if the receiver is an instance of a compact class, this method answers true to: 'aaa' pointsTo: ByteString and I think that's incorrect. Moreoever, you can read the comment of the method "Or stated another way: Answers true if the garbage collector would fail to collect anObject because I hold a reference to it, or false otherwise" That's not true for compact classes. With this change: pointsTo: anObject "Answers true if I hold a reference to anObject, or false otherwise. Or stated another way: Answers true if the garbage collector would fail to collect anObject because I hold a reference to it, or false otherwise" ^ (self instVarsInclude: anObject) or: [(self class indexIfCompact = 0) and: [self class == anObject] ] it works fine. Do you agree with the change? cheers -- Mariano http://marianopeck.wordpress.com

Jan. 6, 2012

Re: [Pharo-project] About ConfigurationOfXMLSupport

by Norbert Hartl

Am 05.01.2012 um 20:52 schrieb StÃ©phane Ducasse: > > On Jan 4, 2012, at 3:59 PM, Norbert Hartl wrote: > >> >> Am 29.12.2011 um 23:04 schrieb StÃ©phane Ducasse: >> >>> Hi guys >>> >>> I thought that XMLSupport was about parsing and XMLNode traversal. >>> So why the configuration contains references to SIXX and Grease Core? >>> >> It is called XMLSupport. So it combines xml support technologies (otherwise it should be named ConfigurationOfXMLParsersAndDOM). I think Michael just dropped the name in and nobody changed it. >> >> The presence of Sixx and the dependency of Grease is my duty (I'm intentionally not writing 'my faul't). I'm working a lot in GemStone and differences between the dialects are a real pain if you try to develop in pharo and deploy in GemStone. As we also need to exchange data we ported Sixx to GemStone. I've put Sixx in the configuration to keep the development of XML parser and Sixx close because Sixx relies on the interface of xml parser pretty much. As every module is a symbol there is no problem. And Sixx is not loaded by default. > > I know what is SIXX but to me you should write a ConfigurationOfSixx, if each package move its clients close to him then > we will end up in a mess. I disagree. There is more than one way to create a mess. One is what you describe! The other one you get by over-engineering things. If you create a configuration for every package that consist of one file only you will get tons of configuration files with hard to maintain dependencies. A bigger mess in my opinion (and experience). You always have to leverage the use and effect of doing things. Configurations can have groups which is an internal separation of things that belong together. As there are more ways to do it I have trouble understanding the "if each package move its clients...". There is no need to have a single approach. If it would be that way it would be good if pharo would just follow ANSI. > >> Sixx is a serializer/deserializer for XML and therefor is using streams. Streams are one of those fine examples where platform differences can drive you nuts. I couldn't understand all the fuzz of not using sport and preferring grease for seaside but only for seaside etc. I had a hard time dealing with platform subtleties for character encoding (yes, I care!) and streams when it comes to dialects. So I decided to introduce grease and made the GemStone port of Sixx depend on streams and character encoding behaviour of grease (Please sue me!). Dale was so kind to make even GemStone Core to depend on Grease to make Xml loadable by the core. > > But put that in ConfigurationOfSixx :) > Well, just do it. I personally would put xml parser, sixx, pastell, other xpath libs and the pull parser in a single configuration file. If someone likes to do XML stuff he/she will be fine to find it maintained in a single place. All of the mentioned libs are single packaged, tiny things. This would probably also help to find an existing lib before implemented your own (search for xpath in the mailing lists). I understand you are looking for something "clean". Well, knock yourself off. I'm more after usable units. Norbert > > >> Later I recognized that in pharo terms this is not possible. I had a discussion with Sven because I wanted to have a zinc port for gemstone. But he was more interested to get zinc close to pharo. So the grease way was not an option and the result is the port to gemstone is still incomplete and hard to maintain. >> >> Sorry for the long answer but this is just another story of how hard it is to have modular systems where all of the mentioned issues wouldn't be that much of a problem. I would wish that we find a good solution to make sources more interchangable between platforms. I don't mean get rid of the dialect differences (because I don't think it will happen) but to design code in a way that platform subtleties can be compensated in an object oriented way. >> >> Norbert >> >> > >

Jan. 6, 2012

Re: [Pharo-project] Misc. newbie questions

by Lukas Renggli

On 6 January 2012 11:20, Peter Hugosson-Miller <oldmanlink(a)gmail.com> wrote: > On 6 jan 2012, at 06:41, "Gerry Weaver" <gerryw(a)compvia.com> wrote: > > 2. There appear to be some tool choices in the Pharo image. I would like to > be able to create a class and it's methods in an editor in one go. I like > being able to see all of the class code at once. Is there a way to do this? > Â I just want to be able to type it all in and accept (evaluate?) all at > once. > > This is an interesting question to me personally. After 15 years of working > exclusively in Smalltalk I've recently been forced to start programming in > Java, where the source code is always (as far as I know) arranged in the way > you describe. > > This organization just emphasizes the dead and compiled nature of Java (and > similar languages), compared to the living objects of Smalltalk, where even > methods are objects, created by sending messages to other objects. Source > code is relegated to being a mere artifact, which can be saved and organized > in any way one wishes, and preferably never shows its ugly face to the coder > :-p Which of course is no argument why Smalltalk code could not be displayed in a more programmer friendly way as a continuous block of text. There is no technical reason why source ranges in text box couldn't correspond to life method objects. Compared to other languages it is extremely tedious in Smalltalk to get an overview over a project, a package, or even a single class or to navigate between entities. > And yes, I really *really* miss a good, object oriented class browser! Eclipse is pretty good, especially with the Java Browsing Perspective. Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 6, 2012

Re: [Pharo-project] Prematurely ending document on purpose with the SAXParser

by Norbert Hartl

Am 06.01.2012 um 13:09 schrieb StÃ©phane Ducasse: > Is the XMLPulParser part of XMLSupport? > No, it is completely different. It is based on the old parser. I wanted to combine those two but didn't find the time to do it. Ken also did a pull parser based Sixx which would be worth to integrate. Would partially solve the resource consumption of Sixx. Norbert > Stef > >>>>> I wonder what to do in this kind of situations. See >>>>> >>>>> 1) XML is one of the most important packages >>>>> 2) There is no mailng-list for xml ? >>>>> 3) Nobody replies and >>>>> 4) You want latest updates from that package >>>>> >>>>> Any suggestion? >>>> >>>> Maybe you could try to reach someone from the administrators/developers directly, there are quite a few on SS. >>>> >>> I'm one of those listed. But jaayer is the developer of the XML package. He picked up Michaels implementation and extended it. So there is only one guy that can give an elaborate answer. >>> Hernan, I don't really understand your problem. It sounds like you need to mess with the method checkEOD in order to get your use case done. While the real problem is that SAX is about to read the whole file at once. And while this is inappropriate for a lot of cases StAX/pull parsers have been implemented. So the real issue is that there is no StAX/pull parser in smalltalk (or at least in pharo). >>> >>> Norbert >>> >>> >> >> Hi, >> >> Of course the ideal would be a using a full StAX implementation, or >> even better a vtd-xml one, that would really be a cool use case for >> attracting more developers into Smalltalk. As there is no >> specification of SAX we are in the consensus line. So while SAX is >> commonly and thought to be used as a read-all solution, there is some >> workaround to stop the reading in Java [*]. So yes, I've used a >> workaround for that case. Today I played with XMLPullParser (StAX) and >> after a few changes I could parse and stop parsing when a specific >> node is reached, example: >> >> | parser | >> parser := XMLPullParser parse: '<?xml version="1.0"?> >> <!DOCTYPE BlastOutput PUBLIC "-//NCBI//NCBI BlastOutput/EN" >> "NCBI_BlastOutput.dtd"> >> <BlastOutput> >> <BlastOutput_program>blastn</BlastOutput_program> >> <BlastOutput_version>BLASTN 2.2.26+</BlastOutput_version> >> <BlastOutput_reference>Zheng Zhang, Scott Schwartz, Lukas Wagner, >> and Webb Miller (2000), "A greedy algorithm for aligning DNA >> sequences", J Comput Biol 2000; >> 7(1-2):203-14.</BlastOutput_reference> >> <BlastOutput_param> >> <Parameters> >> <Parameters_expect>10</Parameters_expect> >> <Parameters_sc-match>1</Parameters_sc-match> >> </Parameters> >> </BlastOutput_param> >> <BlastOutput_iterations>'. >> [ parser isStartTag: 'BlastOutput_param' ] >> whileFalse:[ >> Transcript show: parser text; cr. >> parser next ] >> >> I've sent the changes to Ken Treis so he can integrate them in >> XMLPullParser package. >> Cheers, >> >> HernÃ¡n >> >> http://www.ibm.com/developerworks/xml/library/x-tipsaxstop/ >> http://stackoverflow.com/questions/3405702/using-sax-to-parse-common-xml-el… >> http://stackoverflow.com/questions/1345293/how-to-stop-parsing-xml-document… >> > >

Jan. 6, 2012

Re: [Pharo-project] Prematurely ending document on purpose with the SAXParser

by HernÃ¡n Morales Durand

No, it's a separate package http://www.squeaksource.com/XMLPullParser.html 2012/1/6 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Is the XMLPulParser part of XMLSupport? > > Stef >

Jan. 6, 2012

Re: [Pharo-project] Prematurely ending document on purpose with the SAXParser

by StÃ©phane Ducasse

Is the XMLPulParser part of XMLSupport? Stef >>>> I wonder what to do in this kind of situations. See >>>> >>>> 1) XML is one of the most important packages >>>> 2) There is no mailng-list for xml ? >>>> 3) Nobody replies and >>>> 4) You want latest updates from that package >>>> >>>> Any suggestion? >>> >>> Maybe you could try to reach someone from the administrators/developers directly, there are quite a few on SS. >>> >> I'm one of those listed. But jaayer is the developer of the XML package. He picked up Michaels implementation and extended it. So there is only one guy that can give an elaborate answer. >> Hernan, I don't really understand your problem. It sounds like you need to mess with the method checkEOD in order to get your use case done. While the real problem is that SAX is about to read the whole file at once. And while this is inappropriate for a lot of cases StAX/pull parsers have been implemented. So the real issue is that there is no StAX/pull parser in smalltalk (or at least in pharo). >> >> Norbert >> >> > > Hi, > > Of course the ideal would be a using a full StAX implementation, or > even better a vtd-xml one, that would really be a cool use case for > attracting more developers into Smalltalk. As there is no > specification of SAX we are in the consensus line. So while SAX is > commonly and thought to be used as a read-all solution, there is some > workaround to stop the reading in Java [*]. So yes, I've used a > workaround for that case. Today I played with XMLPullParser (StAX) and > after a few changes I could parse and stop parsing when a specific > node is reached, example: > > | parser | > parser := XMLPullParser parse: '<?xml version="1.0"?> > <!DOCTYPE BlastOutput PUBLIC "-//NCBI//NCBI BlastOutput/EN" > "NCBI_BlastOutput.dtd"> > <BlastOutput> > <BlastOutput_program>blastn</BlastOutput_program> > <BlastOutput_version>BLASTN 2.2.26+</BlastOutput_version> > <BlastOutput_reference>Zheng Zhang, Scott Schwartz, Lukas Wagner, > and Webb Miller (2000), "A greedy algorithm for aligning DNA > sequences", J Comput Biol 2000; > 7(1-2):203-14.</BlastOutput_reference> > <BlastOutput_param> > <Parameters> > <Parameters_expect>10</Parameters_expect> > <Parameters_sc-match>1</Parameters_sc-match> > </Parameters> > </BlastOutput_param> > <BlastOutput_iterations>'. > [ parser isStartTag: 'BlastOutput_param' ] > whileFalse:[ > Transcript show: parser text; cr. > parser next ] > > I've sent the changes to Ken Treis so he can integrate them in > XMLPullParser package. > Cheers, > > HernÃ¡n > > http://www.ibm.com/developerworks/xml/library/x-tipsaxstop/ > http://stackoverflow.com/questions/3405702/using-sax-to-parse-common-xml-el… > http://stackoverflow.com/questions/1345293/how-to-stop-parsing-xml-document… >

Jan. 6, 2012

Re: [Pharo-project] localization

by HernÃ¡n Morales Durand

2012/1/6 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > > For Date/Time localization, there's the LocalePlugin which returns some of > the OS's current Locale's values. > An interface to the CLDR would be nice, but no one's invested in that yet as > far as I know. > I have invested in CLDR parsers, if someone has interest to help me I could set up a project. Cheers HernÃ¡n -- HernÃ¡n Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.

Jan. 6, 2012

Re: [Pharo-project] localization

by Henrik Johansen

On Jan 6, 2012, at 12:03 08PM, Milan Mimica wrote: > Hello! > > I notice many of you are not native English speakers so you must have asked yourself this question before: what are the possibilities of localization in Pharo? I'm mostly interested in date and time localization. I notice there is a class named ChronologyConstants, and sure I can modify it, but how do I do it in a nice way, so that the alterations are saved in my own MC package? > > Moreover, this class alone is not enough. For example, in Croatian, January is not written or pronounced the same when used in a date or used in a enumeration. The English equivalent of today's date would be "6th of January" - notice the "of". > > There is even less subtle weaknesses: you don't get to choose default date and time format. > > Hm, looking at ChronologyConstants again, it seem its purpose never was localization, it is merely a shared pool for constants. > > Do you have any plans for localization? I haven't seen it mentioned. This is a must have in an enterprise-friendly software, you must agree. > > > -- > Milan Mimica > http://sparklet.sf.net For Date/Time localization, there's the LocalePlugin which returns some of the OS's current Locale's values. An interface to the CLDR would be nice, but no one's invested in that yet as far as I know. For manual translations, there's the gettext package in http://www.squeaksource.com/PharoNonCorePackages . Cheers, Henry

Jan. 6, 2012