February 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.4] #14328

by Marcus Denker

14328 ----- Issue 5277: undeclared in FileList: volList http://code.google.com/p/pharo/issues/detail?id=5277 StartupPreferences shouldnt lauch script when you save http://code.google.com/p/pharo/issues/detail?id=5275 -- Marcus Denker -- http://marcusdenker.de

Feb. 11, 2012

Re: [Pharo-project] [squeak-dev] Are Objects really hard?

by Schwab,Wilhelm K

Yes, programming is hard. It's even harder if one is poorly educated and not well read. I don't expect that everyone will have Smalltalk experience, but I would expect someone nearing completion of a PhD in computer science to have at least _heard_ of Smalltalk and Alan Kay. I recently met a very bright count-example to my expectation. The average programmer I meet, has no historical perspective, can't intelligently compare and contrast oo, structured and functional approaches to software implementation. All they seem to care about is this or that "technology" they saw in a glossy ad. Do you recall a talk Alan gave some years back at Stanford? He was on a good rant about how our computer science/engineering departments had let themselves be turned into Java certification mills, and ultimately uttered the words "what has happened to the mighty Standford?" I was a little surprised at his candor (took guts) and agreed with every word he said. The problem is PATHETIC education and self-preparation, IMHO. ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Hernan Wilkinson [hernan.wilkinson(a)10pines.com] Sent: Saturday, February 11, 2012 7:42 AM To: The general-purpose Squeak developers list Cc: VWNC; va-smalltalk(a)googlegroups.com; GNU Smalltalk; Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [squeak-dev] Are Objects really hard? Well... functional programming is hard and not everybody really understands it... structured programming is hard and not everybody really understood it... hmm at the end, programming is hard :-) He gives no reason about his stament nor "demonstration" of it neither... so he has a feeling, me too and a completely different one :-) On Sat, Feb 11, 2012 at 9:21 AM, Janko MivÅ¡ek <janko.mivsek(a)eranova.si<mailto:janko.mivsek@eranova.si>> wrote: Hi guys, Again one interesting topic for this weekend to discuss. David Nolen, a Lisp and JavaScript guy posted in his blog an article titled Illiterate Programming [1] where he said: "...Yet I think Smalltalk still fundamentally failed (remember this is a programming language originally designed to scale from children to adults) because *Objects are really hard* and no-one really understands to this day how to do them right...." He links to Alan Kay post [2] back in 1998 where he talks about problems with inheritance: "Here are a few problems in the naive inheritance systems we use today: confusions of Taxonomy and Parentage, of Specialization and Refinement, of Parts and Wholes, of Semantics and Pragmatics..." Let we concentrate on broader "Objects are really hard and no-one really understands to this day how to do them right" claim and not merely inheritance, please. Best regards Janko [1] http://dosync.posterous.com/illiterate-programming [2] http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-April/009261.ht… -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si -- HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com<http://www.10pines.com/> Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

Feb. 11, 2012

Re: [Pharo-project] 1.4 - better from Jenkins

by Schwab,Wilhelm K

That's if the debugger still works =:0 Good idea though. ________________________________________ From: 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: Friday, February 10, 2012 8:17 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 - better from Jenkins Schwab,Wilhelm K wrote: > Stef, > > I have an idea for something that might be simple enough to make the point. It is confusing though, especially that once an image goes bad, it stays bad, even though (AFAIK, I don't save it after the damage is done). For certainty, you could monitor file timestamps or in the extreme compare md5 checksums on the image at various points. Perhaps the first thing after unzippping a new image add 'self halt' at the top of SmalltalkImage>>snapshot:andQuit: This might help hunt down anything that is forcing an image save without your consent. cheers, -ben

Feb. 11, 2012

Re: [Pharo-project] [squeak-dev] Are Objects really hard?

by Hernan Wilkinson

Well... functional programming is hard and not everybody really understands it... structured programming is hard and not everybody really understood it... hmm at the end, programming is hard :-) He gives no reason about his stament nor "demonstration" of it neither... so he has a feeling, me too and a completely different one :-) On Sat, Feb 11, 2012 at 9:21 AM, Janko MivÅ¡ek <janko.mivsek(a)eranova.si>wrote: > Hi guys, > > Again one interesting topic for this weekend to discuss. David Nolen, a > Lisp and JavaScript guy posted in his blog an article titled Illiterate > Programming [1] where he said: > > "...Yet I think Smalltalk still fundamentally failed (remember this is a > programming language originally designed to scale from children to > adults) because *Objects are really hard* and no-one really understands > to this day how to do them right...." > > He links to Alan Kay post [2] back in 1998 where he talks about problems > with inheritance: > > "Here are a few problems in the naive inheritance systems we use today: > confusions of Taxonomy and Parentage, of Specialization and Refinement, > of Parts and Wholes, of Semantics and Pragmatics..." > > Let we concentrate on broader "Objects are really hard and no-one really > understands to this day how to do them right" claim and not merely > inheritance, please. > > Best regards > Janko > > [1] http://dosync.posterous.com/illiterate-programming > [2] > > http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-April/009261.ht… > > -- > Janko MivÅ¡ek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si > > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

Feb. 11, 2012

[Pharo-project] Are Objects really hard?

by Janko MivÅ¡ek

Hi guys, Again one interesting topic for this weekend to discuss. David Nolen, a Lisp and JavaScript guy posted in his blog an article titled Illiterate Programming [1] where he said: "...Yet I think Smalltalk still fundamentally failed (remember this is a programming language originally designed to scale from children to adults) because *Objects are really hard* and no-one really understands to this day how to do them right...." He links to Alan Kay post [2] back in 1998 where he talks about problems with inheritance: "Here are a few problems in the naive inheritance systems we use today: confusions of Taxonomy and Parentage, of Specialization and Refinement, of Parts and Wholes, of Semantics and Pragmatics..." Let we concentrate on broader "Objects are really hard and no-one really understands to this day how to do them right" claim and not merely inheritance, please. Best regards Janko [1] http://dosync.posterous.com/illiterate-programming [2] http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-April/009261.ht… -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

Feb. 11, 2012

Re: [Pharo-project] Is there an adhoc header field in Fuel?

by Mariano Martinez Peck

On Sat, Feb 11, 2012 at 2:32 AM, Yanni Chiu <yanni(a)rogers.com> wrote: > On 10/02/12 3:45 PM, StÃ©phane Ducasse wrote: > >> this is a good idea. >> > > Hmmm. I think the .zip file approach is the "correct/better" approach to > take to my metadata problem. > > This discussion did turn up a feature of Fuel that was not obvious to me > before - namely, that you can read/write multiple materializations on a > single stream. > > I think that then this deserves at least a page in the documentation, right? -- Mariano http://marianopeck.wordpress.com

Feb. 11, 2012

Re: [Pharo-project] Is there an adhoc header field in Fuel?

by Mariano Martinez Peck

> >> I don't understand. Fuel holding multiple streams ? why? for what? >> > > e.g. for source code. Imagine storing Monticello packages in Fuel so that > the source code is stored in the Fuel file and doesn't have to be written > to the changes file. Instead, a more powerful SourceFilesArray (actually a > source file manager) can maintain a set of source files, including Fuel > files, and fetch source there-from. Hence loading is faster, and the > changes file isn't polluted with code loads, containing only one's own code. > > e.g. for external resources. imagine loading a Fuel package that also > contains some dlls that can be unpacked as required. > > But if you choose this route let me strongly suggest you use the zip file > format. Its very useful with Monticello mcz's to be able to pick them > apart using unzip. > > Ok, I see. That makes sense. However, that won't be part of Fuel, but rather a tool build on top of it. Now we have the Fuel core a simple serializer. FuelMetalevel, an optional package build on top of Fuel core to be able to correctly serialize classes, methods, traits, etc. FuelPackageLoader, an optional package build on top of FuelMetalevel to experiment import/export of packages in a binary way. So....continue with that infrastructure, if there would be a Monticello integration with Fuel, then such package should take care about serializing different things in different streams. But so far, for Fuel core, and I think the best approach is to let is simple as it is now. > >> >>> The the default Fuel system can then automatically ignore 3rd-party >>> data. >>> >> >> I want to make my point clear: Martin proposed an example that solves >> Yanni problem. If you serialize with a stream with a certain position, then >> you have to materialize it with its correct position. Dot. It is perfect >> that the materializer is broken if you do not give him the correct stream. >> Now, I DO agree that there could be another solution rather than adhoc, >> supported by fuel so that BY DEFAULT some data could be set and ignored at >> the same time...so that there is no manipulation of the srteam by the user. >> >> >> >>> Cheers >>>> >>>> >>>> >>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > > -- > best, > Eliot > > -- Mariano http://marianopeck.wordpress.com

Feb. 11, 2012

[Pharo-project] Maybe someone here can give me an idea on where to start

by Friedrich Dominicus

Well it's a somewhat longer story. I have some code to interface via the serial lines. And I want to do that on Windows and Linux. So far so good. Now my code for interfacing to the serial lines works fine on Windows. But it fails on Linux here's the debug.log from Pharo: THERE_BE_DRAGONS_HERE PrimitiveFailed: primitive #primWritePortByName:from:startingAt:count: in SerialPort(#'/dev/ttyUSB0', 9600 baud, 8 bits, 1 stopbits, no parity) failed 11 February 2012 10:56:40 am VM: unix - i686 - linux-gnu - Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.78] Image: Pharo1.3 [Latest update: #13320] SerialPort(Object)>>primitiveFailed: Receiver: SerialPort(#'/dev/ttyUSB0', 9600 baud, 8 bits, 1 stopbits, no parity) Arguments and temporary variables: selector: #primWritePortByName:from:startingAt:count: Receiver's instance variables: port: '/dev/ttyUSB0' baudRate: 9600 stopBitsType: 1 parityType: 0 dataBits: 8 outputFlowControlType: 0 inputFlowControlType: 0 xOnByte: 19 xOffByte: 24 SerialPort(Object)>>primitiveFailed Receiver: SerialPort(#'/dev/ttyUSB0', 9600 baud, 8 bits, 1 stopbits, no parity) Arguments and temporary variables: Receiver's instance variables: port: '/dev/ttyUSB0' baudRate: 9600 stopBitsType: 1 parityType: 0 dataBits: 8 outputFlowControlType: 0 inputFlowControlType: 0 xOnByte: 19 xOffByte: 24 Where do I start or how do I start to solve this error? Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

Feb. 11, 2012

Re: [Pharo-project] git interesting article

by Guido Stepken

Interesting posting. But i don't think, that this is the right model for refactoring, where a lot of 'depreciated classes' (reason: copyright, restructuring, replacement, creating 'orthogonality', whatever) cause much collateral damages in hundreds of packages, like it is in pharo at the moment. IMHO, there are three models necessary with three different cycles going round robin, with different *emphasis*: 1. advancing cycle in development as described in the article 2. refactoring cycle with strong emphasis on sunit and testing 3. package update and compatibility cycle #3 is similar to the 'maintainer model' in Debian development process. Smalltalk *users* (meant: app developers) should overtake, because it's rather in their interest. #2 'Beauty is, where we refactor it': User and core developer interest. #1 core developer only. 'Users' rather destroy, because things get too complicated. (debugger, event handler) regards, Guido Stepken Am 10.02.2012 21:11 schrieb "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr>: > http://nvie.com/posts/a-successful-git-branching-model/ > tx dale for the pointer > stef > >

Feb. 11, 2012

[Pharo-project] Issue 5276: replaced MCMethodDefinition's Definitions class variable with a class instance variable.

by StÃ©phane Ducasse

levente did the following in squeak - replaced MCMethodDefinition's Definitions class variable with a class instance variable. The cached definitions are no longer registered for finalization. - a bit of cleanup around MCDefinition's Instances class variable And I like the idea that we do not stress the finalization. Now we should check that I understand correctly http://code.google.com/p/pharo/issues/detail?id=5276 Stef

Feb. 11, 2012