- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Pharo-users] [COTDC] 98 - ZipFileConstants

by StÃ©phane Ducasse

I defined some constant for the file compression. On Dec 28, 2011, at 7:50 PM, sean(a)clipperadams.com wrote: > 97 classes done > 798 classes remaining > Continuing in Compression... > > Today: ZipFileConstants > > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > p.s. this message was sent from a pharo image. Did you know you could easily do that?! >

Dec. 29, 2011

Re: [Pharo-project] Roeltyper

by StÃ©phane Ducasse

On Dec 28, 2011, at 7:24 PM, Lukas Renggli wrote: >> Yes when I looked at RB (in 99) I guess that they also used existing instances to try to get more >> information but mainly for instance variables. > > I am not aware of such code. RBRefactoryTyper is part of the > refactoring engine since I first looked at it around ESUG 2002. May be it was mentioned in their ecoop paper or in some workshop. I had fun with it when I wrote the message passing control paper in 98 after may be john told me that t was experimental. > It is > relatively hidden, and only used by a few refactorings to provide > better default suggestions (i.e. extract to component). It is also > used in OB to provide a better default class comment template. And in > ECompletion for better suggestions since RoelTyper is not useable > anymore. > >> I would really like to see more work around practical tools that can help us. I have the work on type inference >> from francisco garau on my hard-disc. But this is a pity that nobody build on top of that. > > Never heard of that code. I can put it on a server. This was the master thesis of Francisco Garau. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Dec. 29, 2011

[Pharo-project] [update 1.4] #14276

by StÃ©phane Ducasse

14276 ----- - Issue 5135: Set>>grow buggy for sets with nil. Thanks Igor Stasenko. http://code.google.com/p/pharo/issues/detail?id=5135 - Issue 5130: Remove magicHalo behavior. http://code.google.com/p/pharo/issues/detail?id=5130 Stef and Igor Hacking HazelTracer

Dec. 29, 2011

Re: [Pharo-project] Possible bug in FFI

by Mariano Martinez Peck

On Thu, Dec 29, 2011 at 12:23 AM, ncalexan <ncalexander(a)gmail.com> wrote: > Hello all, > > Long-time reader, first-time poster. Hi and welcome :) > Is FFI fully supported on Pharo? I > installed into the 1.3 OneClick using > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfFFI'; > load. > > ConfigurationOfFFI load. > > All seems fine but > > ExternalAddress gcallocate: 128 > > fails in ExternalAddress>>shallowCopy, complaining that clone is not > understood. > > Bug? Not supported? Misused? > > Indeed, it looks like a bug at least for pharo (where #clone was removed) ExternalAddress >> shallowCopy "Re-implemented to avoid superclass call to #new:" ^self clone But now sure what to replace it with. The method #clone used to be just the call to primitive 148, which is the same as shallowCopy. So I don't understand why we need to reimplement shallowCopy in ExternalAddress. "Re-implemented to avoid superclass call to #new:" since shallowCopy is a primitive, it would only send a message (like #new:) only if the primitive fails. So..I am lost. > Best, > Nick Alexander > > -- > View this message in context: > http://forum.world.st/Possible-bug-in-FFI-tp4241299p4241299.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

Dec. 29, 2011

Re: [Pharo-project] changing the class of an existing object to a subclass

by Mariano Martinez Peck

On Wed, Dec 28, 2011 at 12:08 PM, Ben Coman <btc(a)openinworld.com> wrote: > Schwab,Wilhelm K wrote: > >> Ben, >> >> That's a lot to read. If I'm getting the message, you want to subclass >> ODBCRow and are concerned about Metacello. >> > Point taken. In hindsight too much background info and a mixed message. > Actually it wasn't not a question about Metacello - though my other recent > mention of ConfigurationOfODBC was. I only mentioned ConfigurationOfODBC > here to distinguish it from the ODBC in DBXTalk Just in case of interest, in DBXTalk you CAN access not only by index but by name. rawValueAt: anIndex "It returns the value of the raw at the specified index. No conversion is here, so all values will be String" ^rawValues at: anIndex rawValueNamed: aString "It returns the value of the raw with the specified name. No conversion is here, so all values will be String" ^self rawValueAt: (self columnIndex: aString) And you can also get the values and convert them to smalltalk objects: valueAt: anIndex "It returns the value of the raw at the specified index. Each string returned from openDBX will be converted, if supported, to Squeak types" ^self convertValueAt: anIndex valueNamed: aString "It returns the value of the raw with the specified name. Each string returned from openDBX will be converted, if supported, to Squeak types" ^self convertValueAt: (self columnIndex: aString). Cheers > - and in hindsight that is not the core question. The short version is > "how do I change the class of existing object into one of its subclasses". > I've got it working, but not if I add an instance variable to the subclass. > > FWIW, I suspect I would make some type of wrapper class for the rows >> rather than subclass - the goal being to strive for uses-a vs. is-a. >> >> > I had considered that briefly but was concerned that the wrapped class > needed to understand every message that the wrapped-class understood. I > wanted to use the existing ODBCResultTable which holds the ODBCRows to > contain my new subclass of ODBCRow. I will think further about this. > > Idealistically (and perhaps naively) yours, >> >> > More than I would know. Thanks for your time. -Ben > > Bill >> >> >> ______________________________**__________ >> From: pharo-project-bounces(a)lists.**gforge.inria.fr<pharo-project-bounces(a)lists.gforge.inria.fr>[ >> pharo-project-bounces(a)lists.**gforge.inria.fr<pharo-project-bounces(a)lists.gforge.inria.fr>] >> on behalf of Ben Coman [btc(a)openInWorld.com] >> Sent: Tuesday, December 27, 2011 11:46 PM >> To: Pharo-project(a)lists.gforge.**inria.fr<Pharo-project(a)lists.gforge.inria.fr> >> Subject: [Pharo-project] changing the class of an existing object to a >> subclass >> >> greetings all, >> >> I am using ConfigurationOfODBC in Pharo 1.3. I have had success with >> getting an ODBCResultTable(**OrderedCollection) containing ODBCRow >> containing about 30 fields. By default the fields are accessed by "row >> at: #fieldName" but I wanted to add some convenience methods to instead >> go "row fieldName." My searching and experimentation led me to >> subclassing ODBCRow as EAPPackage and then using "adoptInstance:" on >> each ODBCRow to convert it to the subclass. This was to avoid having to >> having to understand and change any of the ConfigurationOfODBC code. I >> had tried copyFrom: but some of the instance variables inherited from >> ODBCRow were not filled in, generating exceptions in some of the >> inherited methods. I had also considered "become:" but that didn't seem >> appropriate. >> >> Using "adoptInstance:" worked fine until I added a new instance variable >> to EAPPackage. Subsequently for "<primitive: 160 error: ec>", ec = >> #'bad receiver'. The "adoptInstance:" method comment says it follows >> the same rules as "primitiveChangeClassTo:" (yet note that >> "primitiveChangeClassTo:" never worked) >> The "primitiveChangeClassTo:" method comment says "The primitive will >> fail in most cases that you think might work [...] The facility is >> really provided for certain, very specific applications (mostly related >> to classes changing shape) and not for casual use" so I wondered if >> there was another way to achieve this. >> >> The full code is hopefully not too long to include for reference below. >> The use of "adoptInstance:" in the last section listed. >> ------ >> ODBCRow subclass: #EAPPackage >> instanceVariableNames: 'parent' "note adoptInstance works without >> this instance variable, and not with" >> classVariableNames: '' >> poolDictionaries: '' >> category: 'BTC-EA-Explore' >> ------ >> EAPPackage >> name >> ^ self at: #Name >> ------ >> ODBCResultTable subclass: #EAPPackages >> instanceVariableNames: '' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'BTC-EA-Explore' >> ------ >> EAPPackages class >> newFromConnection: connection >> | packages parent | >> packages := (connection query: 'select * from t_package;') execute >> asTable. >> self adoptInstance: packages. >> >> packages do: [ :row | EAPPackage adoptInstance: row. ]. >> >> ^packages. >> ------ >> In a Workspace I successfully evaluate the following three lines without : >> connection := ODBCConnection dsn: 'CIM' user: '' password: ''. >> packages := EAPPackages newFromConnection: connection. >> connection close. >> ------ >> >> I found the ODBCRow instance creation to ODBCResultSet>>fetchRow. One >> alternative I've considered is to somehow pass through a custom >> SomeClass in a variable to replace the hard reference to ODBCRow - but I >> don't want to chase back all the cascading call references. >> >> Is there another way to change an existing object to another class, such >> that it can be specialised with both additional methods and instance >> variables? >> I would appreciate any pointers. >> >> regards, Ben >> >> >> >> >> > > > -- Mariano http://marianopeck.wordpress.com

Dec. 29, 2011

Re: [Pharo-project] [COTDC] 98 - ZipFileConstants

by Ben Coman

sean(a)clipperadams.com wrote: > 97 classes done > 798 classes remaining > Continuing in Compression... > > Today: ZipFileConstants > > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > p.s. this message was sent from a pharo image. Did you know you could easily do that?! > This class defines magic numbers taken from the PKWARE ZIP Application Note [1] approved by ISO/IEC JTC 1/SC 34 N 1621 in July 2011 [2] to be the international normative reference for the zip file format. A class imports these bindings as 'class variables' by including the following in its class definition: poolDictionaries: 'ZipFileConstants' There is a single method on the class side to initialise the values. [1] http://www.pkware.com/documents/casestudies/APPNOTE.TXT [2] http://www.itscj.ipsj.or.jp/sc34/open/1621.pdf Following are pertinent extracts from the PKWARE ZIP Application Note.... All values are stored in little-endian byte order unless otherwise specified. A. local file header signature 4 bytes (0x04034b50) C. Data descriptor: crc-32 4 bytes compressed size 4 bytes uncompressed size 4 bytes F. central file header signature 4 bytes (0x02014b50) I. end of central dir signature 4 bytes (0x06054b50) J. Explanation of fields: * version made by (2 bytes) 0 - MS-DOS and OS/2 (FAT / VFAT / FAT32 file systems) 3 - UNIX 1,2,4-20 not implemented * compression method: (2 bytes) 0 - The file is stored (no compression) 6 - The file is Imploded 8 - The file is Deflated 1-7,9-19,97,98 not implemented * For Methods 8 and 9 - Deflating Bit 2 Bit 1 0 0 Normal (-en) compression option was used. 0 1 Maximum (-exx/-ex) compression option was used. 1 0 Fast (-ef) compression option was used. 1 1 Super Fast (-es) compression option was used. * internal file attributes: (2 bytes) Bits 1 and 2 are reserved for use by PKWARE. The lowest bit of this field indicates, if set, that the file is apparently an ASCII or text file. If not set, that the file apparently contains binary data. Note the following do not appear in the PKWARE ZIP Application Note. Should they be defined elsewhere? "Unix permission bits" DefaultDirectoryPermissions := 8r040755. DefaultFilePermissions := 8r0100666. DirectoryAttrib := 8r040000. FileAttrib := 8r0100000.

Dec. 29, 2011

Re: [Pharo-project] TWM doesn't work without keymappins and keymappings doesn't work

by Sean P. DeNigris

Sean P. DeNigris wrote > > In Pharo 1.3, I get "MetacelloProjectSpecLoadError: No version found for > '2.0' of ConfigurationOfKeymapping" > It looks like Keymapping's version 2.1 overwrote 2.0. If that's what happened, the attached fileout is fixed, but Guillermo can you check it? http://forum.world.st/file/n4241451/ConfigurationOfKeymapping.st ConfigurationOfKeymapping.st -- View this message in context: http://forum.world.st/TWM-doesn-t-work-without-keymappins-and-keymappings-d… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 29, 2011

Re: [Pharo-project] TWM doesn't work without keymappins and keymappings doesn't work

by Sean P. DeNigris

laurent laffont wrote > > Gofer it > squeaksource: 'TilingWindowManager'; > package: 'ConfigurationOfTilingWindowManager'; > load. > (Smalltalk at:#ConfigurationOfTilingWindowManager) loadDevelopment. > (Smalltalk at:#TWMUITheme) beCurrent. > TaskbarMorph showTaskbar: false. > TasklistMorph keepOpen: true. > (Smalltalk at:#TWMBar) perform: #showTWMBar: with: true. > In Pharo 1.3, I get "MetacelloProjectSpecLoadError: No version found for '2.0' of ConfigurationOfKeymapping" -- View this message in context: http://forum.world.st/TWM-doesn-t-work-without-keymappins-and-keymappings-d… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 29, 2011

[Pharo-project] Possible bug in FFI

by ncalexan

Hello all, Long-time reader, first-time poster. Is FFI fully supported on Pharo? I installed into the 1.3 OneClick using Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfFFI'; load. ConfigurationOfFFI load. All seems fine but ExternalAddress gcallocate: 128 fails in ExternalAddress>>shallowCopy, complaining that clone is not understood. Bug? Not supported? Misused? Best, Nick Alexander -- View this message in context: http://forum.world.st/Possible-bug-in-FFI-tp4241299p4241299.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 28, 2011

[Pharo-project] [COTDC] 98 - ZipFileConstants

by sean＠clipperadams.com

97 classes done 798 classes remaining Continuing in Compression... Today: ZipFileConstants Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest p.s. this message was sent from a pharo image. Did you know you could easily do that?!

Dec. 28, 2011