- Pharo-dev - lists.pharo.org

Re: [Pharo-project] RTF reader/writer

by StÃ©phane Ducasse

Thanks! Stef On May 5, 2010, at 9:28 PM, Brian Brown wrote: > Hi Stef, > > I have had this laying around for quite some time, and I don't quite remember what all it can do, but you are welcome to do whatever you wish with it :) > > <RTF-rbb.7.mcz> > > > On May 4, 2010, at 3:30 AM, StÃ©phane Ducasse wrote: > >> Hi guys >> >> Do you know if there is a library somewhere in Smalltalk to deal with RTF writing/saving? >> >> Stef >> _______________________________________________ >> 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

May 5, 2010

Re: [Pharo-project] Help System

by Michael Roberts

I agree with Lukas, although I have already expressed these sentiments in previous threads when I raised my own design concern. For me the point is that the standard old class comment / method comments is not expressive enough to be integrated into such a help system. There is a desire to annotate help above what can be done with the old method (a) via a richer API but use a system that does not depend on the subclass approach (b). Now for Pharo it does not really matter because we put the base classes in, but as Lukas says it does not load in other images that require this code. and my feeling is that the subclass approach still puts the documentation too far from the code that you are documenting. This is what I found a pain trying to integrate some help in the network package. i just ended up not doing it. I don't want to have to put it in another package. Anyway i am not going to go over old ground. i just wanted to say +1. cheers, Mike On Wed, May 5, 2010 at 7:19 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Yes I remember it :) > Kind of pattern :) > Stef >> >>> P.S: I'm still in favour of well structured books in separate >>> Â Â Â packages than mixed code/docu in one package since you >>> Â Â Â may wish to unload docu for deployment/runtime scenarios. >>> >> Hi Torsten, all >> Yes, we had exactly the same discussion (one year ago? I can't believe it) about >> the settings package. An advantage of the builder approach is that >> one can simply choose: >> It is possible to let documentation methods (#helpOn: aBuilder ...) and code >> mixed in a single package without introducing any dependency >> or choose to have two packages, one for the documentation and the >> second for the code. >> Cheers >> Alain >> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 5, 2010

Re: [Pharo-project] RTF reader/writer

by Brian Brown

Hi Stef, I have had this laying around for quite some time, and I don't quite remember what all it can do, but you are welcome to do whatever you wish with it :) On May 4, 2010, at 3:30 AM, StÃ©phane Ducasse wrote: > Hi guys > > Do you know if there is a library somewhere in Smalltalk to deal with RTF writing/saving? > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 5, 2010

Re: [Pharo-project] Help System

by StÃ©phane Ducasse

Yes I remember it :) Kind of pattern :) Stef > >> P.S: I'm still in favour of well structured books in separate >> packages than mixed code/docu in one package since you >> may wish to unload docu for deployment/runtime scenarios. >> > Hi Torsten, all > Yes, we had exactly the same discussion (one year ago? I can't believe it) about > the settings package. An advantage of the builder approach is that > one can simply choose: > It is possible to let documentation methods (#helpOn: aBuilder ...) and code > mixed in a single package without introducing any dependency > or choose to have two packages, one for the documentation and the > second for the code. > Cheers > Alain > >> >> >> >> >> >> _______________________________________________ >> 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

May 5, 2010

Re: [Pharo-project] ConfigurationOfPharo and OmniBrowser

by Dale Henrichs

Alexandre, Using Metacello 1.0-beta.26 and PharoCore-1.1-11335-UNSTABLE (latest update), I get the same results: SHOUT uses the deprecated registerMenu API Refactoring Browser AST-Core-lr.66 is loaded first and the AST-Core-lr.67 is loaded but this probably isn't a problem, although moving the refactoring browser project in the baseline should eliminate the "double load" Nile-Clients-MarianoMartinezPeck.178 still has an issue with #isInMemory not understood, while doing NSAbstractDataStream class>>initialize So I don't think these are Metacello issues...just more work to port these projects to Pharo 1.1:) Dale ----- "Alexandre Bergel" <alexandre(a)bergel.eu> wrote: | > I'm actually working through this scenario right now. | | Hi Dale! | | Any progress? | | Cheers, | Alexandre | | | > Moving OB BEFORE AutomaticMethodCategorizer will load the proper | > version of OB ... with this load order the older version of OB | > shouldn't be loaded by AutomaticMethodCategorizer (this is the area | | > where I suspected a bug in 1.0-beta.26 that is fixed in 1.0-beta. | > 26.1). | > | > However, I have run into an issue with SHOUT using the deprecated | > API and then I ran into an MNU in another part of the system (doing | | > initialization) so I'm trying to determine if this is a problem for | | > Metacello or not ... when I have characterized the issues, I'll send | | > mail... | > | > Dale | > | > | > ----- "Alexandre Bergel" <alexandre(a)bergel.eu> wrote: | > | > | > Thanks Dale for the dedicated answer. I understood you | > correclty? If | > | | > | > I change baseline11: and I put | > | > | > | > project: 'AutomaticMethodCategorizer' | > | > with: | > | > [ spec | > | > className: | > | > 'ConfigurationOfAutomaticMethodCategorizer'; | > | > file: | > | > 'ConfigurationOfAutomaticMethodCategorizer'; | > | > repository: | > | 'http://www.squeaksource.com/MetacelloRepository' | > | > ]; | > | > | > | > | > | > AFTER | > | > | > | > project: 'OB Dev' | > | > with: | > | > [ spec | > | > className: | > | > 'ConfigurationOfOmniBrowser'; | > | > loads: #('Dev'); | > | > file: | > 'ConfigurationOfOmniBrowser'; | > | > repository: | > | 'http://www.squeaksource.com/MetacelloRepository' | > | > ]; | > | > | > | > | > | > then it should work ok ? | > | | > | I understand that if you do this, then the version 1.1.3 of | > | Omnibrowser will be loaded, then AutomaticMethodCategorizer will | | > load | > | | > | the old version of OB. | > | | > | I think that ConfigurationOfAutomaticMethodCategorizer needs to | be | > | updated. | > | I work on it now... | > | | > | Cheers, | > | Alexandre | > | | > | > | > | > | > | > | > | > This implies that ConfigurationOfAutomaticMethodCategorizer will | | > not | > | | > | > load correctly into Pharo 1.1, so the solution is to create a | new | > | > version ConfigurationOfAutomaticMethodCategorizer that will | load | > | > into Pharo 1.1 (i.e. referencing version 1.1.3 of | > | > ConfigurationOfOmniBrowser) and then update | ConfigurationOfPharo | > | > accordingly... | > | > | > | > yes...the problem is that you have to do that in all the confs | | > that | > | | > | > points to OB. | > | > | > | > ..... | > | > | > | > | > | > The nesting level for '1.1.3 [ConfigurationOfOmniBrowser]' and | | > '1.1 | > | | > | > [ConfigurationOfAutomaticMethodCategorizer]' are the same which | > | > means that they are both referenced in '1.1 | > [ConfigurationOfPharo]'. | > | | > | > That was enough to solve this particular problem, but in an | > | > Inspector, you can dive into the directives themselves and | > actually | > | | > | > get to the MetacelloSpec that was used to create the | directive... | > | > | > | > | > | > | > | > Here is what I don't understand. If you have that directive, and | | > you | > | | > | > have ALL that information, can't you guess that if you need to | | > load | > | | > | > the N version of a package and then the version M, where M > N, | | > then | > | | > | > you can skip to load N and just load M directly ? | > | > | > | > In this example, can you DO NOT load OmniBrowser-lr.458 as you | | > know | > | | > | > that after you will load OmniBrowser-lr.469 ? | > | > Or maybe directly about conf: Do not load 1.1 | > | > [ConfigurationOfOmniBrowser] if you know that then you will | need | > | | > | > to load 1.1.3 [ConfigurationOfOmniBrowser] | > | > | > | > Thanks a lot for the explanation dale! | > | > | > | > mariano | > | > | > | > _______________________________________________ | > | > Pharo-project mailing list | > | > Pharo-project(a)lists.gforge.inria.fr | > | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- | > project | > | | > | -- | > | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | > | Alexandre Bergel http://www.bergel.eu | > | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. | | -- | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | Alexandre Bergel http://www.bergel.eu | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 5, 2010

Re: [Pharo-project] Help System

by Alain Plantec

Le 05/05/2010 15:24, Torsten Bergmann a Ã©crit : > P.S: I'm still in favour of well structured books in separate > packages than mixed code/docu in one package since you > may wish to unload docu for deployment/runtime scenarios. > Hi Torsten, all Yes, we had exactly the same discussion (one year ago? I can't believe it) about the settings package. An advantage of the builder approach is that one can simply choose: It is possible to let documentation methods (#helpOn: aBuilder ...) and code mixed in a single package without introducing any dependency or choose to have two packages, one for the documentation and the second for the code. Cheers Alain > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 5, 2010

Re: [Pharo-project] [squeak-dev] Overrides. Evil. Need to do something with it.

by Igor Stasenko

2010/5/5 StÃ©phane Rollandin <lecteur(a)zogotounga.net>: >> myMethod >> Â <doNotOverride> > >> What you think? > > It seems to me that this is half-way from proper defining of an API. > Why not be more explicit by specifying which API relies on that method, > like: > I don't think so. A method, which should not be overridden belongs to a class where its defined. And a class belongs to certain package. So, there is already enough information what API owns that method. And if you are talking about overriding an extension provided by another external package... i.e. when original method has category: *Foo-extensions and installed package tries to override with with own *Bar-extensions it should be prohibited at all, without giving any chances to load this package into a system. > myMethod > Â <API: myGreatApp> > > This would imply that it should not be overidden, but then if the user wants > to override it nonetheless he would know what API he is messing up with. > > Stef > -- Best regards, Igor Stasenko AKA sig.

May 5, 2010

Re: [Pharo-project] Help System

by Lukas Renggli

> "it is a design flaw" > "Being forced to have strong references ... " > "makes it impossible to just include some documentation" > "This doesn't encourage me at all" > "..." > > So many negative statements in one post, look like you had > a bad day today ;) Not really, I was just trying to load a package with help into an image without the HelpSystem loaded. *boom* I thought I could give some feedback before it got adapted more widely. We had exactly the same discussion with the menu and settings system a few months back. > Â a) If you want to provide API help (reference docu) > Â Â Â you DONT HAVE ANY reference or dependency since you can comment your > Â Â Â classes and methods in the usual Smalltalk way using class/method > Â Â Â comments. > Â Â Â No need for "HelpSystem-Core" to be around, NO REFERENCES, > Â Â Â and NO EXCUSE NOT TO document your code ;) Status quo, yes. I see documentation more exposed through the HelpSystem browser though, which i found a really nice way to browse documentation. > Â Â Â Would you call it a design flaw of SUnit to create tests > Â Â Â by subclassing the class "TestCase" so that it is known to > Â Â Â the system as test case and also shows up in the TestRunner? Yes, absolutely. Any other unit testing framework in the world does not force you to subclass from a common superclass when writing tests. > Â 4. By using pragmas (loose coupling) you have to deal > Â Â with the problem that by your parent topic may not be > Â Â there/not be loaded since it can be defined somewhere else > Â Â in the class hierarchy. I would not make the books extensible themselves, that complicates things and is rarely needed in practice. The exact same problem is solved in the settings system quite nicely. > So I was pragmatic and used Plain old Smalltalk classes and method > to define the books (POSCAM). It doesn't have to be pragmas (although I think it should). It could also just be a class side method #buildHelpOn: that is called when opening the browser and that gives each class the possibility to add some documentation. I am just saying that I am not going to create an extra package just for the sake of documentation. Documentation is really crucial and it needs to be super easy to create, otherwise it is simply not going to happen. Creating an extra package is complicated and doesn't give me any benefit as a developer, so very likely I am not going to do it. Lukas -- Lukas Renggli www.lukas-renggli.ch

May 5, 2010

[Pharo-project] Pharo sprint in Brussels

by Johan Brichau

Hi! We are organizing a Pharo sprint in Brussels on June 11 & 12th. An entry has been added to the page http://code.google.com/p/pharo/wiki/PharoSprints Please, add your name if you wish to participate. Some more info on practical issues to follow soon... ---------------------------- Johan Brichau johan.brichau(a)uclouvain.be

May 5, 2010

Re: [Pharo-project] Overrides. Evil. Need to do something with it.

by Simon Denier

On 5 mai 2010, at 15:41, Igor Stasenko wrote: > Hello, > > there is a certain critial places in system, which should not be > overridden by external packages. > Otherwise, it becomes a mess and usually leads to malfunction in key > system parts: compiler, special objects etc. > > I'd like to propose to introduce a special marker pragma for methods, > which should _never_ be overridden by external package. > > myMethod > <doNotOverride> > > an MC code loader should honor this pragma, and do not attempt to > override this method when installing a package > or at least ask user that there is a risk of getting serious problems, > if you override this method. I think that the MC loader should ALWAYS warn user when an extension attempts an override, and let him choose (especially as the system does not allow to revert an override for now). Unfortunately the feature has been broken for long. Damien C proposed a solution a long time ago but it didn't work for me. Perhaps the bug is more subtle. -- Simon

May 5, 2010