- Pharo-dev - lists.pharo.org

[Pharo-project] R: [Moose-dev] numerical method in smalltalk

by Lorenzo Schiavina

Hi Serge, I have developed a package for fuzzy logic computation (in ST). Do you think could be helpful? Grazie Lorenzo -----Messaggio originale----- Da: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] Per conto di Serge Stinckwich Inviato: martedÃ¬ 20 marzo 2012 7.13 A: Pharo-project(a)lists.gforge.inria.fr Cc: Moose-related development Oggetto: Re: [Pharo-project] [Moose-dev] numerical method in smalltalk On Tue, Mar 20, 2012 at 12:45 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Serge, > > There definitely is interest. If you volunteer for mentoring it would be great. Yes sure i can do it. I can even maybe propose some local students. Do you want to co-mentor ? Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

March 20, 2012

Re: [Pharo-project] International Workshop on Smalltalk Technologies 2011

by Stephan Eggermont

Hello Alain, Are there links to the articles, instead of a paywall? Stephan

March 20, 2012

Re: [Pharo-project] Trying to make KomHttpServer load in 1.4

by Philippe Marschall

On 17.03.2012 18:00, StÃ©phane Ducasse wrote: > Hi guys > > I saw that TranscriptStream is deprecated in 1.3 and I was looking at the logic of the Logger. > > I do not understand the use of isTranscriptStream especially since it is defined only on Stream ^ false > and the EmergencyEvaluator which is particularly not respecting the stream protocol. > > Any suggestion? Do you really need KomHttpServer or would KomLight work as well? Cheers Philippe

March 20, 2012

Re: [Pharo-project] Compiler bug!!!

by Marcus Denker

On Mar 20, 2012, at 5:42 PM, Igor Stasenko wrote: > here the fix.. > i can't say that i like it.. but it works. > <compiler-errornode-fix.1.cs> http://code.google.com/p/pharo/issues/detail?id=5528 -- Marcus Denker -- http://marcusdenker.de

March 20, 2012

[Pharo-project] Refactor method

by Dario Trussardi

Hi, i work with Pharo 1.0. I have a DTRConfig class with class method 'pippo'. When i select on it the menu option: refactor method / pushdown option the system display the message: DTRConfig class is not one abstract class I don't understund because it. On other class the refactor method / pushdown option work fine. Thank for any considerations. Dario

March 20, 2012

Re: [Pharo-project] Compiler bug!!!

by Igor Stasenko

here the fix.. i can't say that i like it.. but it works.

March 20, 2012

Re: [Pharo-project] Compiler bug!!!

by Igor Stasenko

The problem is with #newTemp: used for binding a temporary in a block argument - [:foo <<< ] which increments the total number of temps in encoder (nTemps).. and as result, at the point where #fixTemp: is sent, the nTemps = 2, while actually should be = 1. resulting that error code temp having wrong index. and if you look later, the total number of temps in compiled method are not based on nTemps variable of encoder, but actually calculated from scratch: aCompiledMethodClass newBytes: blkSize trailerBytes: trailer nArgs: arguments size nTemps: (encoder supportsClosureOpcodes ifTrue: [| locals | locals := arguments, temporaries, (primErrNode ifNil: [#()] ifNotNil: [{primErrNode}]). encoder noteBlockExtent: block blockExtent hasLocals: locals. locals size] ifFalse: [encoder maxTemp]) here, locals size = 2, not 3 which means, that (storeIntoTemp: 2) won't work, because it lies outside of method's temps range. Here's even more crazy... if we compile code like that: badat: index <primitive: 60 error: x > [:foo | | xx y z | 5]. ^ x Bytecode: <primitive: 60 error: x> 17 <81 45> storeIntoTemp: 5 19 <8F 01 00 05> closureNumCopied: 0 numArgs: 1 bytes 23 to 27 23 <73> pushConstant: nil 24 <73> pushConstant: nil 25 <73> pushConstant: nil 26 <20> pushConstant: 5 27 <7D> blockReturn 28 <87> pop 29 <15> pushTemp: 5 30 <7C> returnTop -- Best regards, Igor Stasenko.

March 20, 2012

[Pharo-project] Pharo 1.4 Tests-Mac - Build # 284 - Still Unstable!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

March 20, 2012

[Pharo-project] Compiler bug!!!

by Igor Stasenko

Here the simple method: at: index <primitive: 60 error: x > ^ x And its bytecode: <primitive: 60 error: x> 13 <81 41> storeIntoTemp: 1 15 <11> pushTemp: 1 16 <7C> returnTop Now, if i add this: at: index <primitive: 60 error: x > [:foo | 5]. ^ x I get following bytecode: <primitive: 60 error: x> 17 <81 42> storeIntoTemp: 2 19 <8F 01 00 02> closureNumCopied: 0 numArgs: 1 bytes 23 to 24 23 <20> pushConstant: 5 24 <7D> blockReturn 25 <87> pop 26 <12> pushTemp: 2 27 <7C> returnTop so, if we ignore the block closure bytecodes, we have: <primitive: 60 error: x> 17 <81 42> storeIntoTemp: 2 26 <12> pushTemp: 2 27 <7C> returnTop The problem is that for method context there are only 2 temps (argument + error code) .. but not 3 (index is zero-based). The fix should be simple.. in code which calculates the temp index for 'error code' temp. -- Best regards, Igor Stasenko.

March 20, 2012

Re: [Pharo-project] Zodiac is cool!

by Sven Van Caekenberghe

On 20 Mar 2012, at 14:05, Camillo Bruni wrote: > We're currently setting up the build-server to include the SqueakSSL plugin. > hence Zodiac should work out of the box :) That would be really nice ! Sven

March 20, 2012