[Pharo-dev] Got some DNU using Spotter but I could not repeat it

Just for the record Got some DNU using Spotter but I could not reproduce it. Stef

Re: [Pharo-dev] How to browse files with Spotter

Thanks! I did a nice videos filtering examples :) What is strange is that #files does not show me the files on my disc. Stef Le 25/2/16 22:31, Tudor Girba a écrit : #files will list files. ./package-cache is a directory. So, you should use: #dir ./pa Cheers, Doru On Feb 25, 2016, at 10:20

Re: [Pharo-dev] [pharo-project/pharo-core] c2b19a: 50611

I love the idea that we get more and better rules! Tx Yuriy Le 25/2/16 14:11, GitHub a écrit : 17685 Add rules to check if Float system classes are referenced https://pharo.fogbugz.com/f/cases/17685

[Pharo-dev] Run time checking with design by contract assertions

Hi, I have downloaded a first version of IceCompiler, a small tool who allow run time checks embedding in pharo classes on Smalltalkhub at http://smalltalkhub.com/#!/~AlainRastoul/IceCompiler If some interested pharoers are willing to give me feedback on this package I would greatly apprecia

Re: [Pharo-dev] [pharo-project/pharo-core] c2b19a: 50611

The cool thing about these rules is that they are specific, and they capture concrete value (the humane assessment way). Please keep this up, Yuriy :). Cheers, Doru > On Feb 25, 2016, at 11:00 PM, stepharo wrote: > > I love the idea that we get more and better rules! > Tx Yuriy > > > Le 25

Re: [Pharo-dev] [pharo-project/pharo-core] c2b19a: 50611

You are welcome. By adding more rules I also get better idea about the requirement for their model. So keep requests coming :) Uko > On 25 Feb 2016, at 23:00, stepharo wrote: > > I love the idea that we get more and better rules! > Tx Yuriy > > > Le 25/2/16 14:11, GitHub a écrit : >> 17685 A

[Pharo-dev] another difference since spur migration

compare the bytecode of this code |outerContext local1 remote1 | outerContext := thisContext. local1 := 1. remote1 := 3. (1 to:1 ) do:[:index| | rlocal2 rlocal3 | rlocal2 := index. remote1:= rlocal2 / 3. rlocal3 := remote1. rlocal3 := outerContext]. local1 := remote1. thisContext me

Re: [Pharo-dev] Got some DNU using Spotter but I could not repeat it

Hi, Was it not the SubscriptOutOfBounds error? This is because of Rubric, but it should not appear anymore in the latest Pharo with the fix of Marcus. Cheers, Doru > On Feb 25, 2016, at 10:56 PM, stepharo wrote: > > Just for the record > > Got some DNU using Spotter but I could not reproduc

Re: [Pharo-dev] How to browse files with Spotter

You mean if you just say #files, nothing appears? That is because the top level #files and #directories do not appear when the query is empty, and right now we only consider a query to be non-empty when there is at least one non #filter character. But, when you dive in a folder, you should see

Re: [Pharo-dev] [bloc] feature envy -> move method close to data?

Sorry but I do not buy your argument. BlElement is in charge and it delegates it to BlShape. This is a quite common pattern and this is more logical that the object responsible for the shape drawing draw it in fact. It was like that in Bloc before so I do not see why this is not possible now.

Re: [Pharo-dev] [Bloc] MDLColor and new gradient

Ok now I would like to start to have the notion of Palette and Gradient close to Color in Pharo. And Bloc and others can use it. Le 25/2/16 13:32, Aliaksei Syrel a écrit : We will come back to theme, style, colors later. Much later. On Feb 24, 2016 5:16 PM, "stepharo"

Re: [Pharo-dev] Is there a plan to have refreshing values in debugger?

Le 25/2/16 13:39, Tudor Girba a écrit : we now want to play with FastTable to see if it would be fast enough. I really hope ;) Stef

Re: [Pharo-dev] ZTimestamp improvement

Le 25/2/16 15:07, Blondeau Vincent a écrit : I implemented some tests for the slice. You should be able to reuse them. So cool :) Tx vincent! -Message d'origine- De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de Sven Van Caekenberghe Envoyé : jeudi 25 février

Re: [Pharo-dev] ZTimestamp improvement

Hi Vincent, I did it almost the same, but not quite. The reason is that I use #readOptionalSeparatorFrom: in multiple places. For ZTimestamp the TZ stuff is purely optional while parsing, it always operates in UTC from then on. === Name: ZTimestamp-SvenVanCaekenberghe.54 Author: SvenVanCaekenber

Re: [Pharo-dev] How to browse files with Spotter

#files will list files. ./package-cache is a directory. So, you should use: #dir ./pa Cheers, Doru > On Feb 25, 2016, at 10:20 PM, stepharo wrote: > > Doru > > I started to reproduce some of your videos. > I tried to reproduce your videos but I cannot find how I can browse for > example the

[Pharo-dev] How to browse files with Spotter

Doru I started to reproduce some of your videos. I tried to reproduce your videos but I cannot find how I can browse for example the package-cache. I tried . #files package-cache #files ./package-cache #files But I could not get the list of the current files on the folder image. Stef

Re: [Pharo-dev] Recursion inside #doesNotUnderstand: method. Why?

Hi, Because when you are receiving a DNU, you have the possibility to implement the method before resuming the exception. If you choose to implement the method, the message is sent again to the newly created method and the execution restarts. Vincent De : Pharo-dev [mailto:pharo-dev-boun...@l

Re: [Pharo-dev] Recursion inside #doesNotUnderstand: method. Why?

I don’t think so: Put a halt here: …ifTrue: [self halt. aMessage sentTo: self]… 1. Open a playground 2. Do: Object new toto You should have a debugger that pops. Don’t close it. 3. Go in Nautilus, implement toto on Object 4. Click on proceed in the debugger. You shou

Re: [Pharo-dev] Recursion inside #doesNotUnderstand: method. Why?

Am 25.02.2016 6:30 nachm. schrieb "Aliaksei Syrel" : > > Just a guess, maybe to allow method adding from debugger and then ability to continue execution? > > Cheers, > Alex > > On Thu, Feb 25, 2016 at 5:56 PM, Denis Kudriashov wrote: >> >> Hi. >> >> Does anybody know why #doesNotUnderstand: is imp

Re: [Pharo-dev] Recursion inside #doesNotUnderstand: method. Why?

Hi Denis, On Thu, Feb 25, 2016 at 8:56 AM, Denis Kudriashov wrote: > Hi. > > Does anybody know why #doesNotUnderstand: is implemented with recursion at > the end? > > doesNotUnderstand: aMessage > | exception resumeValue | > (exception := MessageNotUnderstood new) > message: aMessage; > receive

Re: [Pharo-dev] Recursion inside #doesNotUnderstand: method. Why?

Maybe in past it was used to create methods in debugger on the fly. But now it is not. I just check it. I removed recursion logic and methods creation continue working in debugger. Maybe we should remove this strange behaviour 2016-02-25 17:56 GMT+01:00 Denis Kudriashov : > Hi. > > Does anybody k

Re: [Pharo-dev] Recursion inside #doesNotUnderstand: method. Why?

Just a guess, maybe to allow method adding from debugger and then ability to continue execution? Cheers, Alex On Thu, Feb 25, 2016 at 5:56 PM, Denis Kudriashov wrote: > Hi. > > Does anybody know why #doesNotUnderstand: is implemented with recursion at > the end? > > doesNotUnderstand: aMessage

[Pharo-dev] Recursion inside #doesNotUnderstand: method. Why?

Hi. Does anybody know why #doesNotUnderstand: is implemented with recursion at the end? doesNotUnderstand: aMessage | exception resumeValue | (exception := MessageNotUnderstood new) message: aMessage; receiver: self. resumeValue := exception signal. * ^exception reachedDefaultHandler* * ifTrue: [

Re: [Pharo-dev] debugger versus primitive 19 "simulation guard"

I revert this case in 17698 2016-02-25 12:24 GMT+01:00 Ben Coman : > Trying to debug step two times into... > [ 'a' ] newProcess > ...hangs the image. > > It works okay with... > Pharo5.0 update: #

[Pharo-dev] [pharo-project/pharo-core]

Branch: refs/tags/50613 Home: https://github.com/pharo-project/pharo-core

[Pharo-dev] [pharo-project/pharo-core] f90141: 50613

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: f9014105d5211bb4d78aabd1278956e126bb00c3 https://github.com/pharo-project/pharo-core/commit/f9014105d5211bb4d78aabd1278956e126bb00c3 Author: Jenkins Build Server Date: 2016-02-25 (Thu, 25 Feb 2016

Re: [Pharo-dev] [Bloc] Do we want or

2016-02-25 15:25 GMT+01:00 Clément Bera : > > > 2016-02-23 18:03 GMT+01:00 Eliot Miranda : > >> >> >> On Tue, Feb 23, 2016 at 12:47 AM, stepharo wrote: >> >>> Hi >>> >>> I saw that something or >>> I do not know why but I have the impression that is >>> better. >>> Because we may have code not

Re: [Pharo-dev] [Bloc] Do we want or

2016-02-23 18:03 GMT+01:00 Eliot Miranda : > > > On Tue, Feb 23, 2016 at 12:47 AM, stepharo wrote: > >> Hi >> >> I saw that something or >> I do not know why but I have the impression that is >> better. >> Because we may have code not present and still want to load the code. >> > > Given the c

Re: [Pharo-dev] [pharo-project/pharo-core] 93fd3c: 50612

not clear in the message, but this issue also makes SDL2 work (a first iteration, there will be problems probably) > On 25 Feb 2016, at 14:45, GitHub wrote: > > 17236 unload NativeBoost (spur migration) > https://pharo.fogbugz.com/f/cases/17236 >

Re: [Pharo-dev] [Bloc] Do we want or

2016-02-23 12:00 GMT+01:00 Ben Coman : > On Tue, Feb 23, 2016 at 5:33 PM, Tudor Girba wrote: > > Hi, > > > > At the moment, it is used for documentation purposes in Bloc. It is part > of the effort of Alex to document Bloc thoroughly. I think it is an > interesting idea, in that we would have a s

Re: [Pharo-dev] ZTimestamp improvement

I implemented some tests for the slice. You should be able to reuse them. > -Message d'origine- > De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de > Sven Van Caekenberghe > Envoyé : jeudi 25 février 2016 14:57 > À : Pharo Development List > Objet : Re: [Pharo-dev] ZT

Re: [Pharo-dev] ZTimestamp improvement

Yes I saw what you did and indeed the same fix needs to be applied to ZTimestamp. I will do it after adding some tests. Thx! > On 25 Feb 2016, at 14:06, Blondeau Vincent > wrote: > > Hello, > > I use Ztimestamp to parse a date but the time zone offset is wrongly set: > (DateAndTime readTimez

Re: [Pharo-dev] [bloc] why redefining new is not enough?

On 25-02-16 14:00, Alain Plantec via Pharo-dev wrote: >interesting. >can you elaborate ? Basically it says I can only be tested when I have a valid space, and you get a really complex one to test with, the one where everything else is running in. Having that space, it tends to be difficult not

[Pharo-dev] [pharo-project/pharo-core]

Branch: refs/tags/50612 Home: https://github.com/pharo-project/pharo-core

Re: [Pharo-dev] [Bloc] Do we want or

There is also to indicate explicitly that user must check for nil. There are only a few methods in element (#owner and some collection related methods like "find element such that") that may return nil. Ideally syntax checker should take into account that method can return nil and indicate it som

[Pharo-dev] [pharo-project/pharo-core]

Branch: refs/tags/50611 Home: https://github.com/pharo-project/pharo-core

[Pharo-dev] ZTimestamp improvement

Hello, I use Ztimestamp to parse a date but the time zone offset is wrongly set: (DateAndTime readTimezoneOffsetFrom: '+0530' readStream) printString gives '0:05:00:00' instead of '0:05:30:00'. See https://pharo.fogbugz.com/f/cases/17693/Time-offset-parsing-is-false for the DateAndTime issue.

Re: [Pharo-dev] [bloc] why redefining new is not enough?

Well, it is not *important* for design what method is redefined new or basicNew in order to set space. My question is why do we need at all to set space? It means that element created (not added) while spaceA is running can not be used in or added to spaceB. The only reason that I know is a possibi

[Pharo-dev] [pharo-project/pharo-core] c2b19a: 50611

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: c2b19a15475f784e06cbcf617d7e304632e16de4 https://github.com/pharo-project/pharo-core/commit/c2b19a15475f784e06cbcf617d7e304632e16de4 Author: Jenkins Build Server Date: 2016-02-25 (Thu, 25 Feb 2016

Re: [Pharo-dev] [bloc] why redefining new is not enough?

An we need NullSpace to be default value. On Feb 25, 2016 2:06 PM, "Aliaksei Syrel" wrote: > Well, it is not *important* for design what method is redefined new or > basicNew in order to set space. My question is why do we need at all to set > space? It means that element created (not added) whil

Re: [Pharo-dev] [Moose-dev] Re: Call for action for Roassal

Oh, I missed this one :). So, now I can refactor the code that is still using the RTEdge class side methods :). Great! Thanks, Doru > On Feb 25, 2016, at 1:59 PM, Alexandre Bergel wrote: > > Oh, but this has been in Roassal for many months (I have implemented since > right after ESUG). You

Re: [Pharo-dev] [Bloc] stroke width and layout measure

no On Feb 25, 2016 1:48 PM, "Nicolai Hess" wrote: > > > 2016-02-25 13:30 GMT+01:00 Aliaksei Syrel : > >> I did not finish with shape yet. >> >> For arbitrary path it is not possible in cairo to render stroke inside >> (really inside) of the shape and take stroke into account to render >> children

Re: [Pharo-dev] [bloc] why redefining new is not enough?

--- Begin Message --- Hello Stephan, > On 25 Feb 2016, at 13:30, Stephan Eggermont wrote: > > On 25-02-16 12:31, Alain Plantec via Pharo-dev wrote: > >the space may be needed during #initialize. > > I would strongly advice against that. That makes it untestable interesting. can you elaborate ?

Re: [Pharo-dev] Is there a plan to have refreshing values in debugger?

> On 25 Feb 2016, at 13:39, Tudor Girba wrote: > > Hi, > > The support for polling is available since more than 1 year. The problem is > that it is too slow to render the tree using MorphTreeMorph. We wanted to > wait until Reflectivity would allow us to capture all objects events, but as >

Re: [Pharo-dev] [bloc] feature envy -> move method close to data?

--- Begin Message --- > On 25 Feb 2016, at 12:51, stepharo wrote: > > To me this is pre optimisation > > I do not see why we cannot do > > BlElement>>drawOnAthensCanvas: aCanvas > > self shape drawOnAthensCanvas: aCanvas with: self > > so far only localBounds from BlElement are used. t

Re: [Pharo-dev] [Bloc] stroke width and layout measure

2016-02-25 13:30 GMT+01:00 Aliaksei Syrel : > I did not finish with shape yet. > > For arbitrary path it is not possible in cairo to render stroke inside > (really inside) of the shape and take stroke into account to render > children. Such behavior to some extent can be simulated but it really >

Re: [Pharo-dev] [bloc] why redefining new is not enough?

--- Begin Message --- > > > well… is not forbidden, of course… > but many frameworks use basicNew as a way of obtain *explicitly* > non-initialized objects (voyage does that, for instance). ok > >> >>> that’s why we have new and basicNew :) >> >> the space may be needed during #initialize

Re: [Pharo-dev] [bloc] why redefining new is not enough?

> On 25 Feb 2016, at 13:34, Clément Bera wrote: > > Hi, > > when redefining new you don't have to use super: > > BlElement class>>new > ^ self basicNew > basicSpace: BlUniverse default runningSpace; > initialize; > yourself > > IMO that's a better practice that re

Re: [Pharo-dev] [bloc] feature envy -> move method close to data?

All arbitrary shapes are being drawing in the same way and it is enough to have only one method. Allowing shape to render itself would lead to misunderstanding: bloc user would have to look into two places (element and shape) to find out where drawing actually happens. On Feb 25, 2016 12:56 PM, "st

Re: [Pharo-dev] Is there a plan to have refreshing values in debugger?

Hi, The support for polling is available since more than 1 year. The problem is that it is too slow to render the tree using MorphTreeMorph. We wanted to wait until Reflectivity would allow us to capture all objects events, but as that will not happen in Pharo 5, we now want to play with FastTa

Re: [Pharo-dev] [bloc] why redefining new is not enough?

Hi, when redefining new you don't have to use super: BlElement class>>new ^ self basicNew basicSpace: BlUniverse default runningSpace; initialize; yourself IMO that's a better practice that redefining basicNew. Usually basicNew is only redefined when you cannot insta

Re: [Pharo-dev] [Moose-dev] Re: Call for action for Roassal

Hi, We discussed this before. Try to draw a hierarchy using classes and inheritance objects (so, without using the class to superclass navigation). Something like this: view := RTMondrian new. view nodes: classes. view edges objects: inheritances; connectFrom: #superclass to: #subclass. view la

Re: [Pharo-dev] [bloc] why redefining new is not enough?

> On 25 Feb 2016, at 12:32, Alain Plantec via Pharo-dev > wrote: > > > From: Alain Plantec > Subject: Re: [Pharo-dev] [bloc] why redefining new is not enough? > Date: 25 February 2016 at 12:37:59 GMT+1 > To: Pharo Development List > > > >> On 25 févr. 2016, at 11:49, Esteban Lorenzano wr

Re: [Pharo-dev] [Bloc] stroke width and layout measure

I did not finish with shape yet. For arbitrary path it is not possible in cairo to render stroke inside (really inside) of the shape and take stroke into account to render children. Such behavior to some extent can be simulated but it really complicates things. So I want to add in contract that it

Re: [Pharo-dev] [Bloc] MDLColor and new gradient

We will come back to theme, style, colors later. Much later. On Feb 24, 2016 5:16 PM, "stepharo" wrote: > I do not know. > May be. > > Le 23/2/16 10:30, Denis Kudriashov a écrit : > > Hi > > 2016-02-23 9:13 GMT+01:00 stepharo : > >> May be we should have some Palette >> >> And we could have (brai

Re: [Pharo-dev] [Moose-dev] Call for action for Roassal

Do you have an example? I am not sure to understand. Alexandre > On Feb 25, 2016, at 12:40 PM, Tudor Girba wrote: > > This is very cool. We will all benefit from this documentation. > > One thing that I would still like to see fixed before the release is the edge > building (this problem of

Re: [Pharo-dev] [bloc] why redefining new is not enough?

On 25-02-16 12:31, Alain Plantec via Pharo-dev wrote: >the space may be needed during #initialize. I would strongly advice against that. That makes it untestable Stephan

Re: [Pharo-dev] [bloc] feature envy -> move method close to data?

To me this is pre optimisation I do not see why we cannot do BlElement>>drawOnAthensCanvas: aCanvas self shape drawOnAthensCanvas: aCanvas with: self so far only localBounds from BlElement are used. And to me this is really strange to have an object responsible for the drawing not doin

[Pharo-dev] Is there a plan to have refreshing values in debugger?

Hi Is there a plan to have refreshed values (instance variables) in debugger and inspector? This is super annoying to have to refresh the complete list in the debugger to see new values of instance variables. Why we cannot put back the old pulling behavior and in the future use reflectivity?

Re: [Pharo-dev] [Moose-dev] Call for action for Roassal

This is very cool. We will all benefit from this documentation. One thing that I would still like to see fixed before the release is the edge building (this problem of not being able to properly specify random objects to be taken into account when building edges). Could we work on that? Cheers,

Re: [Pharo-dev] [bloc] why redefining new is not enough?

--- Begin Message --- > On 25 févr. 2016, at 11:49, Esteban Lorenzano wrote: > > this is bad… redefining basicNew should not be done, never, never, never. why ? > that’s why we have new and basicNew :) the space may be needed during #initialize. this is why the initialization of the space is

[Pharo-dev] debugger versus primitive 19 "simulation guard"

Trying to debug step two times into... [ 'a' ] newProcess ...hangs the image. It works okay with... Pharo5.0 update: #50495 NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 By: Esteban Lorenzano Jenkins build #14904 Unix built

Re: [Pharo-dev] [bloc] why redefining new is not enough?

this is bad… redefining basicNew should not be done, never, never, never. that’s why we have new and basicNew :) Esteban > On 25 Feb 2016, at 09:52, stepharo wrote: > > BlElement class>>basicNew >"Redefined to set the space of the element" > >^ super basicNew basicSpace: BlUniverse de

Re: [Pharo-dev] Spotter - shortcut display on categories

okay, that makes sense. cheers -ben On Thu, Feb 25, 2016 at 6:11 PM, Tudor Girba wrote: > Hi, > > We added it intentionally at the beginning so that you can continue typing > without being disturbed. The idea is that you can do something like: > - GT > - Cmd+b > - In > > ==> #Classes GTIn > > Fo

Re: [Pharo-dev] Spotter - shortcut display on categories

Hi, We added it intentionally at the beginning so that you can continue typing without being disturbed. The idea is that you can do something like: - GT - Cmd+b - In ==> #Classes GTIn For this scenario, it feels more natural to have the cursor at the end. On the other hand, the whole text shif

Re: [Pharo-dev] [bloc] feature envy -> move method close to data?

--- Begin Message --- Hello, very good remark. This is one of the main consequence of the design review we made recently. In the first design, this was the case, the drawing was delegated. For now, it is a known issue of the current design. Cheers Alain > On 25 févr. 2016, at 09:56, stepharo wrote

Re: [Pharo-dev] [bloc] feature envy -> move method close to data?

Hi, Good question. The reason we want to have the morph be responsible because subclasses might decide to draw in a different way regardless of the shape being used. This gives us the maximum freedom for more specific blocs. Still, this is something to experiment with once we have more complic

Re: [Pharo-dev] GTSpotter displayed shortcut glitch

ok Le 24/2/16 19:00, Tudor Girba a écrit : Hi, On Feb 24, 2016, at 6:00 PM, stepharo wrote: Hi doru and andrei I saw that you are displaying the shortcuts that can be used and this is good. Now may be I got it wrong but Cmd + M is not for implementors everywhere else it is Cmd + m

[Pharo-dev] [bloc] feature envy -> move method close to data?

Hi Blockers I do not really understand why drawOnAthensCanvas: is not defined on BlShape (especially when we see how many self space are defined in this method. And this is one of the few things I thought I understood from bloc (grouping the rendering in a separate object). drawOnAthensCanvas

[Pharo-dev] [bloc] why redefining new is not enough?

BlElement class>>basicNew "Redefined to set the space of the element" ^ super basicNew basicSpace: BlUniverse default runningSpace why redefining new is not enough? Ok now back to the mooc videos :(

Re: [Pharo-dev] fork during debugging to auto spawn new debugger

Le 23/2/16 15:14, Denis Kudriashov a écrit : Hi Ben 2016-02-23 14:08 GMT+01:00 Ben Coman >: Maybe if somehow a Process new it was being debugged and the new process inherited that state. I plan to introduce inheriting state for spawn processes. Idea is

Re: [Pharo-dev] About contents of Pharo by Example updated

It would be ok for me. Now I need to understand how I can create a newpage in pillar Stef Le 24/2/16 20:05, Tudor Girba a écrit : Hi, I think this is a good idea. Another idea would be to point people to the help and then institute a help page per-tool policy. We can just create empty items

Re: [Pharo-dev] short spotter demos

Thanks I was going to do some of them. So I will copy what you did. Le 24/2/16 21:38, Tudor Girba a écrit : Hi, The recent debates around Spotter, showed that some of its features are not well understood. In an effort to document it more thoroughly I created a couple of (very short) videos. T