Re: [Pharo-project] new Cog VMs

On 01.01.2011 21:38, Eliot Miranda wrote: > Hi All, > >there are new versions of both the SimpleStackBasedCogit and the > StackToRegisterMappingCogit Cog VMs in VM.r2337/ > & VM.r2338/ > r

Re: [Pharo-project] new Cog VMs

I'm probably doing something obviously wrong, but I have no luck with the Cog VM. It crashes immediately on startup even with the stock OneClick image. I downloaded the Pharo-1.1.1 OneClick images. Fetched the latest coglinux.tgz (r2340), untarred it into the pharo directory and just trying to r

Re: [Pharo-project] Xtreams updates: positioning, slicing and stitching

"Francisco Ortiz Peñaloza" wrote: > Hi Martin, thanks i'll try it later! > > It would help if you could provide a Metacello configuration for it. Yes, something like that is clearly needed, but I'm still finding my way around the environment. However at the moment Xtreams don't have any prerequis

Re: [Pharo-project] Xtreams updates: positioning, slicing and stitching

Hi Martin, thanks i'll try it later! It would help if you could provide a Metacello configuration for it. Cheers, Francisco On Sat, Jan 1, 2011 at 6:03 PM, wrote: > I updated the Xtreams port (http://www.squeaksource.com/Xtreams) over the > holidays to catch up with the state on VW side. The p

Re: [Pharo-project] An intuitive (or screwed) #copyFrom:

I would like to add to the tally. Changing Object>>copyFrom: to Object>>copyStateFrom: makes for me a lot more sense that changing (in fact by the creation of) OrderedCollection>>copyFrom: to OrderedCollection>>copyFromIndex: Except we do agree /in limine/ that OrderedCollection>>copyFrom:to: s

Re: [Pharo-project] source.lukas-renggli.ch is down

Seems that it remains down still. A lot of things depending of the Lukas server are not working :( 2010/12/29 Torsten Bergmann : > and it is one of the reasons why the hudson build fails :( > > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/lastFailedBuild/console > > Even when Luk

Re: [Pharo-project] Graph library in Smalltalk - Need for advices

Check out JUN for Smalltalk. http://aokilab.kyoto-su.ac.jp/jun/index.html -- View this message in context: http://forum.world.st/Graph-library-in-Smalltalk-Need-for-advices-tp3092747p3170556.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Re: [Pharo-project] new Cog VMs

Hi All, there are new versions of both the SimpleStackBasedCogit and the StackToRegisterMappingCogit Cog VMs in VM.r2339/ & VM.r2340/ respectively. These contain fixes for rounding bug cau

Re: [Pharo-project] Issue 3502 in pharo: DNU while parsing

Updates: Cc: stephane.ducasse Labels: Milestone-1.2 Comment #1 on issue 3502 by torsten@astares.de: DNU while parsing http://code.google.com/p/pharo/issues/detail?id=3502 (No comment was entered for this change.)

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken

Comment #5 on issue 3436 by rydier: #copyFrom: is broken http://code.google.com/p/pharo/issues/detail?id=3436 If we end up deprecating and reimplementing, at least make the "new" implementation in SequenceableCollection, where it can be found in STX and GnuST. I still don't think it's a go

[Pharo-project] Issue 3502 in pharo: DNU while parsing

Status: Accepted Owner: torsten@astares.de New issue 3502 by torsten@astares.de: DNU while parsing http://code.google.com/p/pharo/issues/detail?id=3502 ($A to: $Z) do: [:each | Transcript show: '|*'; show: each asString; show: '>Index: ';

Re: [Pharo-project] new Cog VMs

On 1 January 2011 22:27, Eliot Miranda wrote: > > > On Sat, Jan 1, 2011 at 1:23 PM, Igor Stasenko wrote: >> >> I built fresh Cog VM using cmake configs. >> >> Pharo 1.2 tests still crashing with segfault. > > So how exactly do I reproduce this?  Image, OS, action etc... > Try running tests in la

Re: [Pharo-project] new Cog VMs

Mac os Take the latest pharo image here: https://gforge.inria.fr/frs/download.php/28098/PharoCore-1.2beta-12283.zip open the test runner run the tests and boum Esteban and igor got the same. but only when the tests are all run not when a particular test is run.

Re: [Pharo-project] new Cog VMs

On Sat, Jan 1, 2011 at 1:23 PM, Igor Stasenko wrote: > I built fresh Cog VM using cmake configs. > > Pharo 1.2 tests still crashing with segfault. So how exactly do I reproduce this? Image, OS, action etc... > Here the stack dump: > > 0xbff638f0 M CompiledMethod(Object)>becomeForward: 46127

Re: [Pharo-project] new Cog VMs

Eliot I took r2338 And I run the test of the latest Pharo 1.2 and I get a crash. Now may be this is related with the problem with the linkedList fix that andreas suggested. Stef Process: Croquet [26661] Path:/Users/ducasse/Desktop/Cog.app/Contents/MacOS/Croquet Identifi

Re: [Pharo-project] new Cog VMs

I built fresh Cog VM using cmake configs. Pharo 1.2 tests still crashing with segfault. Here the stack dump: 0xbff638f0 M CompiledMethod(Object)>becomeForward: 461278460: a(n) CompiledMethod 0xbff63914 M CompiledMethod>setSourcePointer: 461278460: a(n) CompiledMethod 0xbff63930 M CompiledMethod>s

[Pharo-project] :)

roel wuyts sent me that nice snippet :) | wishStream adjectives | wishStream := WriteStream with: 'For 2011 I wish you '. adjectives := { 'fun' . 'exotic' . 'brilliant' . 'extraordinary' }. { 'research' . 'students' . 'artefacts' . 'conferences'} do: [:e | wishStream nextPu

Re: [Pharo-project] new Cog VMs

Hi All, there are new versions of both the SimpleStackBasedCogit and the StackToRegisterMappingCogit Cog VMs in VM.r2337/ & VM.r2338/ respectively. These contain fixes for another bad pc m

Re: [Pharo-project] An intuitive (or screwed) #copyFrom:

+1 From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Saturday, January 01, 2011 2:59 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pha

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken

Updates: Status: Accepted Labels: Milestone-1.3 Comment #4 on issue 3436 by stephane.ducasse: #copyFrom: is broken http://code.google.com/p/pharo/issues/detail?id=3436 I suggest to use copyStateFrom: and add copyFrom: in String.

Re: [Pharo-project] An intuitive (or screwed) #copyFrom:

On 1 January 2011 20:59, Stéphane Ducasse wrote: > I like copyStateFrom: as a name > > lukas >        there is copyFrom:to: >        and copyFrom: make a lot of sense as copyFrom: index until the end. > +1 in the presence of #copyFrom:to: the current implementation of #copyFrom: is misleading. We

[Pharo-project] Xtreams updates: positioning, slicing and stitching

I updated the Xtreams port (http://www.squeaksource.com/Xtreams) over the holidays to catch up with the state on VW side. The primary changes are updates/fixes of the positioning API and a cleanup/extension of the slicing API. The slicers are replaced by much simpler #slicing setup and the inver

Re: [Pharo-project] An intuitive (or screwed) #copyFrom:

I like copyStateFrom: as a name lukas there is copyFrom:to: and copyFrom: make a lot of sense as copyFrom: index until the end. Stef

Re: [Pharo-project] An intuitive (or screwed) #copyFrom:

right please open a bug entry and provide cs :) Stef > Yes, this method name is unfortunate... > > I think we should just rename the method and tag copyFrom: as deprecated. And > some versions later we'll implement copyFrom: as we think is appropriate. > > Cheers, > Adrian > > BTW Sebastian,

Re: [Pharo-project] An intuitive (or screwed) #copyFrom:

Lukas, I must respectfully disagree: it is also quite similar to #copyFrom:to:, and behaves *completely* differently from same. #copyFrom: really should have a more intention-revealing name. Bill From: pharo-project-boun...@lists.gforge.inria.fr [ph

Re: [Pharo-project] An intuitive (or screwed) #copyFrom:

Peter, Feel free to beat me to pointing out silent failures; I'm glad I'm not alone in seeing them as something to be found and eliminated, and it never hurts for the truth to be heard from multiple directions. Bill From: pharo-project-boun...@lists.g

Re: [Pharo-project] An intuitive (or screwed) #copyFrom:

Hehehe. While I was considering whether or not to chip in on this thread, two thoughts passed through my mind. The first was that this is one of those annoying silent failures that Wilhelm would surely pick up on (so I didn't need to bring it up). The second was that #copyFrom: really should be ca

Re: [Pharo-project] new Cog VMs

Hi Philippe, On Sat, Jan 1, 2011 at 4:06 AM, Philippe Marschall wrote: > On 31.12.2010 03:02, Eliot Miranda wrote: > > > > > > > > > > Hi All, > > > > I've released a new version of Cog that has a substantially > > improved code generator along the lines of Peter Deutsch's HPS > > (VisualWo

Re: [Pharo-project] An intuitive (or screwed) #copyFrom:

Quite some software (Seaside, Mondrian, Magritte, Pier, ...) depends on the current implementation of #copyFrom:, as it is an extremely efficient way to remember and restore the state of an object: rememberReceiverDuring: aBlock previous := self shallowCopy. ^ aBlock ensure: [ self copyFro

Re: [Pharo-project] An intuitive (or screwed) #copyFrom:

Wow. In fairness, Dolphin has one or two such oddities. IIRC, the confusion there is that external arrays (DOUBLE, DWORD, etc.) respond to #copyFrom:to: in terms of bytes, not elements. The problem in this case appears to be that 'a string with some stuff in it' copyFrom:5 should blow up

Re: [Pharo-project] An intuitive (or screwed) #copyFrom:

Yes, this method name is unfortunate... I think we should just rename the method and tag copyFrom: as deprecated. And some versions later we'll implement copyFrom: as we think is appropriate. Cheers, Adrian BTW Sebastian, I think your energy would be better invested into producing a changeset

Re: [Pharo-project] An intuitive (or screwed) #copyFrom:

HI sebastian If I remember correctly you are not the only one bitten by it :) so we should do something Object>>copyFrom: anotherObject "Copy to myself all instance variables I have in common with anotherObject. This is dangerous because it ignores an object's control over its own ins

Re: [Pharo-project] An intuitive (or screwed) #copyFrom:

On 1 January 2011 18:15, Sebastian Sastre wrote: > ('if this isn''t broken' copyFrom:  15) ~= 'broken' ifTrue:['this is > screwed'] ifFalse:['this is intuitive'] my first thought about it was that it should answer own copy , starting from 15th element :) > Evaluate that in any Pharo workspace a

Re: [Pharo-project] [squeak-dev] loading of codetalk fails due to

thanks! On Sat, Jan 1, 2011 at 18:38, Mariano Martinez Peck wrote: > Hi I think it fails because lukas server is down. You can check it on the > browser. > > cheer > > mariano > > On Sat, Jan 1, 2011 at 6:36 PM, Enrico Spinielli > wrote: >> >> hi, >> loading codetalk from potsdam now fails with

Re: [Pharo-project] [squeak-dev] loading of codetalk fails due to

Hi I think it fails because lukas server is down. You can check it on the browser. cheer mariano On Sat, Jan 1, 2011 at 6:36 PM, Enrico Spinielli < enrico.spinie...@googlemail.com> wrote: > hi, > loading codetalk from potsdam now fails with > Error: The spelling dictionary cannot be downloaded

[Pharo-project] loading of codetalk fails due to

hi, loading codetalk from potsdam now fails with Error: The spelling dictionary cannot be downloaded from . I think this is due to recent changes in RB (which codetalk loads) http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg2

[Pharo-project] An intuitive (or screwed) #copyFrom:

('if this isn''t broken' copyFrom: 15) ~= 'broken' ifTrue:['this is screwed'] ifFalse:['this is intuitive'] Evaluate that in any Pharo workspace and it will show you. Reported here. Status? invalid Came on guys. Really? I ask because, if so, situation goes like this: A. we think again and d

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken

Comment #3 on issue 3436 by sebastianconcept: #copyFrom: is broken http://code.google.com/p/pharo/issues/detail?id=3436 I don't get it. When you take any non squeak based smalltalk you'll see that #copyFrom: is consistent and intuitive. When you take Pharo you get that: 1. it's broken even

Re: [Pharo-project] [squeak-dev] Proper Smalltalk lots of classes

Hello Jimmie, I had to do something similar a while ago. I had to support a complex XML schema for a standard message format of the Dutch government (StUF). The Java implementation used JAXB to generate a few thousand data objects. Very clumsy. In Smalltalk I made some code to generate Magritte

Re: [Pharo-project] about growing streams and allocating buffers

On 01.01.2011 15:07, Stéphane Ducasse wrote: >> Hi >> >> I've been doing some performance work lately in Seaside. Long story >> short Seaside (and I guess AIDA too) spends of if it's rendering time in >> WriteStream (#nextPutAll:, #nextPut:). >> >> The way WriteStream >> #pastEndPut: behaves is not

Re: [Pharo-project] about growing streams and allocating buffers

On 01.01.2011 14:39, Levente Uzonyi wrote: > On Sat, 1 Jan 2011, Philippe Marschall wrote: > >> Hi >> >> I've been doing some performance work lately in Seaside. Long story >> short Seaside (and I guess AIDA too) spends of if it's rendering time in >> WriteStream (#nextPutAll:, #nextPut:). >> >>

Re: [Pharo-project] about growing streams and allocating buffers

> Hi > > I've been doing some performance work lately in Seaside. Long story > short Seaside (and I guess AIDA too) spends of if it's rendering time in > WriteStream (#nextPutAll:, #nextPut:). > > The way WriteStream >> #pastEndPut: behaves is not really ideal for > Seaside. It grows the underlyi

[Pharo-project] about growing streams and allocating buffers

Hi I've been doing some performance work lately in Seaside. Long story short Seaside (and I guess AIDA too) spends of if it's rendering time in WriteStream (#nextPutAll:, #nextPut:). The way WriteStream >> #pastEndPut: behaves is not really ideal for Seaside. It grows the underlying collection by

[Pharo-project] [OT] questions answered on stackexchange: Why do good programmers have ugly websites?

Funny. Really funny. Especially this one: " Just be thankful there's more than just a command-prompt. " I hope that with Pharo we have enough 'bad' programmers, which can make good designs.. otherwise we're in trouble :) -- Best regards, Igor Stasenko AKA sig.

Re: [Pharo-project] Issue 3500 in pharo: Create deprecated13

looks fine as to me. On 1 January 2011 12:35, wrote: > Status: Fixed > Owner: stephane.ducasse > > New issue 3500 by stephane.ducasse: Create deprecated13 > http://code.google.com/p/pharo/issues/detail?id=3500 > > We should create a package deprecated13 as one of the first move in 1.3. > > > > >

Re: [Pharo-project] new Cog VMs

On 31.12.2010 03:02, Eliot Miranda wrote: > > > > > Hi All, > > I've released a new version of Cog that has a substantially > improved code generator along the lines of Peter Deutsch's HPS > (VisualWorks) and various of Ian Piumarta's VMs. These all use a simple > tecnique to identify c

Re: [Pharo-project] Issue 3501 in pharo: Remove 1.1 deprecated methods and publish them in a separate package

Updates: Status: Accepted Comment #3 on issue 3501 by stephane.ducasse: Remove 1.1 deprecated methods and publish them in a separate package http://code.google.com/p/pharo/issues/detail?id=3501 we should pay attention that some methods are tagged 1.1 but this is better to key them i

Re: [Pharo-project] Issue 3501 in pharo: Remove 1.1 deprecated methods and publish them in a separate package

Comment #2 on issue 3501 by stephane.ducasse: Remove 1.1 deprecated methods and publish them in a separate package http://code.google.com/p/pharo/issues/detail?id=3501 http://code.google.com/p/pharo/issues/detail?id=2733

Re: [Pharo-project] Issue 3501 in pharo: Remove 1.1 deprecated methods and publish them in a separate package

Comment #1 on issue 3501 by stephane.ducasse: Remove 1.1 deprecated methods and publish them in a separate package http://code.google.com/p/pharo/issues/detail?id=3501 related to 2733

[Pharo-project] Issue 3501 in pharo: Remove 1.1 deprecated methods and publish them in a separate package

Status: Fixed Owner: stephane.ducasse Labels: Milestone-1.3 New issue 3501 by stephane.ducasse: Remove 1.1 deprecated methods and publish them in a separate package http://code.google.com/p/pharo/issues/detail?id=3501 1.1 deprecated methods should be packaged in a separate package and unloa

[Pharo-project] fixing deprecation process once for all

I took 5 min and wrote down that http://code.google.com/p/pharo/wiki/DeprecationProcess comment if you want.

[Pharo-project] Issue 3500 in pharo: Create deprecated13

Status: Fixed Owner: stephane.ducasse New issue 3500 by stephane.ducasse: Create deprecated13 http://code.google.com/p/pharo/issues/detail?id=3500 We should create a package deprecated13 as one of the first move in 1.3.

Re: [Pharo-project] realized and learned something today :)

Thanks stan :) If you are looking for a master topic let us know :) Now my point was more on us getting reality check than students not adoring our language. Stef > It vastly depends on the way it's presented. I'm a forth year student > myself, I've been working for several years in java shops

Re: [Pharo-project] WeakArray>>isFinalizationSupported

Eliot I was replying and I throw away the mail :) I already applied my new year resolution :) Stef PS: we know all that we should have better deprecation policy. We apply that but deprecation is good for little changes not huge ones. > > > On Fri, Dec 31, 2010 at 11:50 AM, Guillermo Polito >

Re: [Pharo-project] WeakArray>>isFinalizationSupported

On Dec 31, 2010, at 8:50 PM, Guillermo Polito wrote: > Oh, come on... > > Levente, we all agree with you. Pharo is trying to use that deprecation > policy since some months ago... Sometimes people make mistakes (me included) > and don't do it, but we agreed that we have to deprecate and rem

Re: [Pharo-project] Proper Smalltalk lots of classes

> Hello, > > I am porting the FIX protocol to Squeak/Pharo. > http://www.fixprotocol.org/ > > It is the Financial Information eXchange protocol. It is used by many firms > in the financial industries, stocks, forex, etc. Excellent! > > There is good documentation and also a semi-reference