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

Re: [Pharo-project] Tests broken with Citezen
by StÃ©phane Ducasse Oct. 6, 2010

Oct. 6, 2010

have a look at the configuration you can pick noWeb. Stef On Oct 6, 2010, at 7:17 PM, Schwab,Wilhelm K wrote: > Damien, > > FWIW, I use Citezen but not Pier etc. I need a good BibTeX parser (which you provide) to parse incoming entries (typically originating from Google Scholar). I then add fields for my own comments (which get edited as I work) and a URL to full text and save the result to intermediate storage. To limit the scope of damage and because it does no harm otherwise, I store each BibTeX entry in a separate file and, on demand, glue them together into a largely unreadable mess (bibtex does fine with it) that I put adjacent to the offending manuscript as a .bib file. > > The way most journals of interest to me release full text articles, the workflow is awful. To not go afoul of copyright law, I store the articles out of public view (and not merely by obscurity). Worse than that, I have to make a local copy of the article and then upload it to the Seaside app, after which things start to work as I intended. I would much prefer to give the Seaside app a URL to the article, but things don't work that way. It's clunky, but the result is very useful to me. > > In short, Citezen is useful by itself, and you have at least one such user. The biggest problem I have had to date was that ConfigurationOfCitezen originally loaded Seaside,which was prematurely forcing 3.0 on me; the current configuration works great. I suspect I won't even notice the change to FileSystem. > > Thanks for a good tool!! > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Damien Pollet [damien.pollet(a)inria.fr] > Sent: Wednesday, October 06, 2010 9:02 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Tests broken with Citezen > > On Wed, Oct 6, 2010 at 14:53, Alexandre Bergel <alexandre(a)bergel.eu> wrote: >> There is no implementor of #fieldKeysToRemove > > yes, probably a missing constant method. > I should also remove the dependency to Rio and use Filesystem instead, > but my next preoccupation is to get the scripting/validation to work. > You're free to hack on the Pier stuff. > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > > _______________________________________________ > 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

2 1

Re: [Pharo-project] [squeak-dev] Re: Smalltalk at: #Foo - needs clarification
by StÃ©phane Ducasse Oct. 6, 2010

Oct. 6, 2010

This is why the image does not use Smalltalk at: but the at: method is still defined in SmalltalkImage. > Stef, > > You raise a good point about helping to improve code, and I would MUCH rather see us try "aClass environment" for a while before introducing name spaces. Dolphin started leaning toward environments a long time ago, and suddenly "class names" were messages to the environment, and I was completely blown away by the potential power of it. I started in 2002 to remove hardcoded Smalltalk at: and replace them by self class environment for the reason that having the possibility to have different systemDictionary instance can help us for: bootstrapping the compiler, building atomic laoding like VW for example. > > So, I'm very open to the idea. However, I don't see any harm in ( Smalltalk at:#SomethingNotYetInstalled ), which I have had to use extensively in Migrate's image building code. Is there a better way to do the same thing? > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > Sent: Wednesday, October 06, 2010 12:31 PM > To: The general-purpose Squeak developers list > Cc: Pharo Development > Subject: Re: [Pharo-project] [squeak-dev] Re: Smalltalk at: #Foo - needs clarification > > On 6 October 2010 19:08, Andreas Raab <andreas.raab(a)gmx.de> wrote: >> On 10/6/2010 6:58 AM, Igor Stasenko wrote: >>> >>> Hello, >>> >>> just wanna ask, is this part of API will be deprecated in future? >>> (in Pharo, it put under 'to clean later' category). >>> >>> And if yes, then what will be correct (dialect-agnostic) way to access >>> globals? >>> >>> Smalltalk globals at: #Foo ? >>> >>> I thought that #at: #at:put: (and some others) >>> historically is a part of Smalltalk protocol, and should stay there to >>> support legacy code and cross-dialect code. >>> >>> >>> What you thoughts about it? >> >> The base dictionary access methods (#at:, #at:put:, #at:ifAbsent:) should >> remain in Smalltalk for compatibility. Then it's a matter of where that >> request is being delegated. >> > > Yes, i am also thinking that for compatibility it should stay. > > > Then i think in modern code, a most future-proof way is > > self class environment at: #Foo > > since it completely avoids any kind of early-binding. > > >> Cheers, >> - Andreas >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > 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

2 1

Re: [Pharo-project] System Tracer
by StÃ©phane Ducasse Oct. 6, 2010

Oct. 6, 2010

On Oct 6, 2010, at 7:18 PM, Eliot Miranda wrote: > > > On Wed, Oct 6, 2010 at 7:31 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > generate a new image. > > But that's not what it does. Yes I know gnerates = clone in my mail. > t merely clones an image, which is a long way form building an image form source. *That*'s a useful project. John Maloney's lovely MicroSqueak is a good starting point for ideas (basically have a copy of a kernel subset of the system in a namespace and generate a fresh image from that). Do you have a pointer on the code of john. We are looking at bootstrap code right now. > > On Oct 6, 2010, at 2:23 PM, Alexandre Bergel wrote: > > > Hi! > > > > What do you want to achieve? > > > > Cheers, > > Alexandre > > > > > > On 6 Oct 2010, at 05:36, Gabriel HernÃ¡n Barbuto wrote: > > > >> Hi > >> > >> Does anyone know where I can find the system tracer that is currently > >> in use in Pharo? > >> > >> Bests > >> Gabriel > >> > >> _______________________________________________ > >> 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 > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > _______________________________________________ > > 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

1 0

[Pharo-project] Bug in Pharo compiler?
by James Ladd Oct. 6, 2010

Oct. 6, 2010

Hi All, Currently im running the Redline Smalltalk compiler (http://redline.st) over the Pharo source to make sure that it is compatible with Pharo. What I noticed while compiling the class BitBlt is that an instance variable is also used as a method argument name! If you try and do this with the environment you get a "name already defined" error, yet it is in the source. Not sure what to do about it? Rgs, James.

2 2

[Pharo-project] FFI number of arguments
by Schwab,Wilhelm K Oct. 6, 2010

Oct. 6, 2010

Hello all, I have been bumping into some functions with large numbers of arguments. One in particular would be best handled in the image if at all possible. The following might be the answer: http://thread.gmane.org/gmane.comp.lang.smalltalk.squeak.general/98538/focu… Have any of you done this with >15 (or whatever the cutoff is) arguments? Bill

6 19

[Pharo-project] KomHttpServer in pharo 1.2
by Guillermo Polito Oct. 6, 2010

Oct. 6, 2010

*HttpServices class>>platform ^SmalltalkImage current platformName* Should be *HttpServices class>>platform ^OSPlatform platformName* How can it be adapted to pharo? Cheers!

5 8

Re: [Pharo-project] System Tracer
by StÃ©phane Ducasse Oct. 6, 2010

Oct. 6, 2010

generate a new image. On Oct 6, 2010, at 2:23 PM, Alexandre Bergel wrote: > Hi! > > What do you want to achieve? > > Cheers, > Alexandre > > > On 6 Oct 2010, at 05:36, Gabriel HernÃ¡n Barbuto wrote: > >> Hi >> >> Does anyone know where I can find the system tracer that is currently >> in use in Pharo? >> >> Bests >> Gabriel >> >> _______________________________________________ >> 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2 1

[Pharo-project] Tests broken with Citezen
by Alexandre Bergel Oct. 6, 2010

Oct. 6, 2010

Hi! Citezen seems to not run on a 11414. CZEntry>>clean self class fieldKeysToRemove do: [:each | (self hasFieldWithKey: each) ifTrue: [self removeFieldWithKey: each]] There is no implementor of #fieldKeysToRemove I would like to use Citezen to generate the Research webpage on Pharo. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 2

[Pharo-project] Smalltalk at: #Foo - needs clarification
by Igor Stasenko Oct. 6, 2010

Oct. 6, 2010

Hello, just wanna ask, is this part of API will be deprecated in future? (in Pharo, it put under 'to clean later' category). And if yes, then what will be correct (dialect-agnostic) way to access globals? Smalltalk globals at: #Foo ? I thought that #at: #at:put: (and some others) historically is a part of Smalltalk protocol, and should stay there to support legacy code and cross-dialect code. What you thoughts about it? -- Best regards, Igor Stasenko AKA sig.

3 3

[Pharo-project] Tool for: Image2 - Image1 > FileOut?
by Stefan Marr Oct. 6, 2010

Oct. 6, 2010

Hello: I got here two images without sufficient development history, source code management, or change sets. One of the images is the basis point and the other contains all the relevant code I need to file out somehow so that it represents a diff which can be filed into the base point image easily. I am only interested in classes, methods, and their meta infos, so general state in the image is not a problem at the moment. If it would be only about methods, that would be easy, since I can find out whether it is a changed/new method by locking at the fileIndex. However, for classes that does not work out. How can I find out whether they changed or were added? That seems to be only possible if they were actually commented... Is there any known tool which could produce me a diff/fileOut/changeSet from two given images? Or might there be any other information in the image I could use to create one myself? Thanks and best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

2 1