Re: [Pharo-dev] PharoV30.sources in Pharo 4.0 download

[Marcus Denker]

> On 01 Apr 2015, at 22:23, Chris Cunningham  wrote:
> 
> Is there a plan to condense changes and build a new sources file for the 4.0 
> release?
> 

Yes! We will do it next week.

And the nature of the whole mechanism is not very nice: it means that the 
artefact on the build server
is not the artefact of release… always very annoying, as the code that you call 
once a year tend to be broken…

Marcus

> Just curious
> -cbc
> 
> On Wed, Apr 1, 2015 at 1:18 PM, Max Leske  > wrote:
> 
>> On 01 Apr 2015, at 22:12, Dmitri Zagidulin > > wrote:
>> 
>> I noticed that the Pharo 4.0 full distribution zip file off of 
>> Pharo.org/download  contains PharoV30.sources 
>> (and not, say, PharoV40.sources).
>> This is true for all 3 platforms:
>> - http://files.pharo.org/platform/Pharo4.0-mac.zip 
>> 
>> - http://files.pharo.org/platform/Pharo4.0-win.zip 
>> 
>> - http://files.pharo.org/platform/Pharo4.0-linux.zip 
>> 
>> 
>> Is there a typo in a CI job somewhere? 
> 
> No, those are the latest sources :) The version simply tells you with what 
> image the sources have been created (I presume). Anyway, the version number 
> is not important.
> 

Re: [Pharo-dev] GitHub SquareBracketAssociates

[Sean P. DeNigris]

Jigyasa Grover wrote
> I have sent an invite to join SquareBracketsAssociates.

Thanks!



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/GitHub-SquareBracketAssociates-tp4816789p4816868.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

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

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] d1d881: 40592

[GitHub]

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: d1d881e547a6da3c8fe57208aa0833ad4a65e336
  
https://github.com/pharo-project/pharo-core/commit/d1d881e547a6da3c8fe57208aa0833ad4a65e336
  Author: Jenkins Build Server 
  Date:   2015-04-02 (Thu, 02 Apr 2015)

  Changed paths:
M 
Komitter.package/KomitSliceUI.class/instance/initialization/initializeWidgets.st
A 
MonticelloGUI.package/MCFileRepositoryInspector.class/instance/accessing/selectedPackageAncestors.st
M MonticelloGUI.package/MCFileRepositoryInspector.class/instance/morphic 
ui/packageSelection_.st
M MonticelloGUI.package/MCFileRepositoryInspector.class/instance/morphic 
ui/versionHighlightEmphasis_.st
M 
MonticelloGUI.package/MCSliceMaker.class/instance/actions/downloadIssueSummary.st
R ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script591.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script592.st
R ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40591.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40592.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForIssues_.st

  Log Message:
  ---
  40592
15280 issue grabber should use new tracker app
https://pharo.fogbugz.com/f/cases/15280

15234 monticello is not showing right status when working with branches
https://pharo.fogbugz.com/f/cases/15234

http://files.pharo.org/image/40/40592.zip

[Pharo-dev] Anonymous Subclasses and Slots

[Stefan Marr]

Hi:

Is the following expression supposed to work?

Class new compile: ‘foo: a ^ a'

I am on the latest Pharo 4 image.
There is a test doing `Behavior new compile:` in BehaviorTest>>#testCompile but 
this test doesn’t use any variables/arguments, so the problem does not appear.

The issue is that the `layout` of the result of `Class new` is nil, which cases 
the compiler to fail, when it sends #allSlots when determining the 
instanceScope.

Thanks
Stefan

-- 
Stefan Marr
INRIA Lille - Nord Europe
http://stefan-marr.de/research/

[Pharo-dev] Playground opening issue

[Franck Warlouzet]

Hello,

Open a new Playground when one of the others is already opened is ok, but if 
all of the Playgrounds are minimalized, the new one will be opened very very 
small (Too small to be used).

Cheers,
Franck
  

Re: [Pharo-dev] Playground opening issue

[Franck Warlouzet]

I opened a Fogbugz entry :

https://pharo.fogbugz.com/f/cases/15281/Playground-opening-issue

From: franck.warlou...@hotmail.fr
To: pharo-dev@lists.pharo.org
Date: Thu, 2 Apr 2015 15:26:31 +0200
Subject: [Pharo-dev] Playground opening issue




Hello,

Open a new Playground when one of the others is already opened is ok, but if 
all of the Playgrounds are minimalized, the new one will be opened very very 
small (Too small to be used).

Cheers,
Franck

  

Re: [Pharo-dev] 14606 Really Important bug - Can't see some variables values while debugging closure

[Max Leske]

> On 02 Apr 2015, at 00:29, Nicolai Hess  wrote:
> 
> 2015-04-01 18:56 GMT+02:00 Ben Coman  >:
> Issue 14606 [1] is tagged "Really Important" where evaluating
> 
> | t1 t2 t3 t4 t5 t6 |
> t1 := 1.
> t2 := 2.
> t3 := 3.
> t4 := 4. 
> t5 := 5 .
> t6 := 6.
> [t5 := 50.
>  t6 := 60.
>  t3 + t4.
>  1 halt.
> ] value
> 
> => can't see the value of t4, t5, t6.
> 
> I've just submitted a possible solution for this, but its a bit late before 
> release for such a change - so I'm asking for "all hands in" to help stress 
> test it.  You don't need to review code, just please merge latest slice 14606 
> into your normal working image and report your experience.
> 
> cheers -ben
> 
> [1] https://pharo.fogbugz.com/default.asp?14606#124466 
> 
> 
> 
> 
> Here is a minimal example that does not work with your fix. (condensed from 
> the failing test case)
> 
> [ :x :y | 
> (thisContext tempNamed: 'x') inspect.
> (1 to: 1)
> do: [ :i | 
> | k l |
> k := y.
> l := x.
> (thisContext tempNamed: 'x') inspect ] ] value: 1 value: 23
> 
> Both inspector windows should show the same value for the argument 'x'. 
> But the result is 
> 1. inspector -> 1
> 2. inspector -> 23
> 
> 

Before loading the slice, both inspectors show ‘1’. That can’t be right either…

Max

[Pharo-dev] Icon in New list morph.

[Yuriy Tymchuk]

Hi,

can someone help me to figure out how the icon in a NewList is working? Because 
when when you add an IconicButton, you have a border showing up on hover and 
background becoming darker on click. Now when I create a standalone 
IconicButton I don’t get this actions… Does anyone have any idea?

Uko

[Pharo-dev] (a = b) ifTrue: []

[Anne Etien]

Hi,

I wanted to write a method that:
- if (a = b) checks other conditions that are specified in the ifTrue block and 
return this (boolean) value
- returns false if (a!=b) 

So I wrote:
myMethod
^ (a=b) ifTrue: [ aBlockCheckingConditions].

However, when (a!=b) the method returns nil (since false ifTrue: [] returns 
nil). So do you have an idea how I can do to express that or should I 
mandatorily wrote also an ifFalse:?

The problem comes certainly because we don’t know that the ifTrueBlock will 
return a boolean.

If you have prettier ideas, I am interested in.

Anne

Re: [Pharo-dev] (a = b) ifTrue: []

[Max Leske]

> On 02 Apr 2015, at 17:15, Anne Etien  wrote:
> 
> Hi,
> 
> I wanted to write a method that:
> - if (a = b) checks other conditions that are specified in the ifTrue block 
> and return this (boolean) value
> - returns false if (a!=b) 
> 
> So I wrote:
> myMethod
>   ^ (a=b) ifTrue: [ aBlockCheckingConditions].
> 
> However, when (a!=b) the method returns nil (since false ifTrue: [] returns 
> nil). So do you have an idea how I can do to express that or should I 
> mandatorily wrote also an ifFalse:?

I always use #ifTrue:ifFalse: in such situations, just to be explicit. It makes 
reading the code easier too.

> 
> The problem comes certainly because we don’t know that the ifTrueBlock will 
> return a boolean.

There’s been years of debate on this :)

> 
> If you have prettier ideas, I am interested in.
> 
> Anne

Cheers,
Max

Re: [Pharo-dev] Bloc Roadmap

[stepharo]

sean

if you can collect the answers to your question and put them into the 
pillar doc :), this can help.


Stef

Le 1/4/15 23:29, Sean P. DeNigris a écrit :

>> > yes, we know, we are preparing a documentation.
>> Great! Is the WIP publicly available (e.g. in one of our 
Pillar/GitHub repos)? Btw. the class comments are reeeally great! I'm 
only talking about documenting design rationale.

> We did them twice :)
I'm probably looking in the wrong place. Do you have links?

> To doc in on github pharo progress.
This? 
https://github.com/SquareBracketAssociates/PharoInProgress/blob/master/Bloc/Bloc.pillar


> Continue to ask so that we can extract the information from his mind.
Okay! :)
Cheers,
Sean


View this message in context: Re: Bloc Roadmap 

Sent from the Pharo Smalltalk Developers mailing list archive 
 at 
Nabble.com.

[Pharo-dev] Can we have basicRaw in GTInspector?

[stepharo]

This morning GTInspector was so slow that it blocked the complete system 
on the machine of Cyril. :(
We can tell him that he is stupid to have a bad machine or we could try 
to use this to see how

we can help our users.

So we had to use basicInspect to get our job done (once we ctrl-. to 
escape the render hell)

because raw uses a tree morph.

Why raw cannot reproduce the old simple and working basicInspect
then we could have a "basic" inspect on double click to avoid to use 
this bad tree and that we can work.


just try to on RubSmalltalkCodeMode class>>#menuOn: to get the feel. 
Even on my superfast machine is

is sluggish.

I really think that we should support backdoors.
We need to have a mini browser, a mini debugger and a working inspector.

Setf

Re: [Pharo-dev] (a = b) ifTrue: []

[Peter Uhnák]

>
> >   ^ (a=b) ifTrue: [ aBlockCheckingConditions].


Boolean is still just an object, so you can use a cascade
^ (a=b)
ifTrue: [ aBlockCheckingConditions];
yourself

Peter

Re: [Pharo-dev] Can we have basicRaw in GTInspector?

[Cyril Ferlicot]

Yeah.
We was checking the CCMockConfiguration>>#mockProperty for Cocoon and if we
go litteral4 -> 1 -> keyword
here that freez a lot.
And if you try to open something else you can put your image on the trash.

On 2 April 2015 at 17:30, stepharo  wrote:

> This morning GTInspector was so slow that it blocked the complete system
> on the machine of Cyril. :(
> We can tell him that he is stupid to have a bad machine or we could try to
> use this to see how
> we can help our users.
>
> So we had to use basicInspect to get our job done (once we ctrl-. to
> escape the render hell)
> because raw uses a tree morph.
>
> Why raw cannot reproduce the old simple and working basicInspect
> then we could have a "basic" inspect on double click to avoid to use this
> bad tree and that we can work.
>
> just try to on RubSmalltalkCodeMode class>>#menuOn: to get the feel. Even
> on my superfast machine is
> is sluggish.
>
> I really think that we should support backdoors.
> We need to have a mini browser, a mini debugger and a working inspector.
>
> Setf
>
>


-- 
Cheers
Cyril Ferlicot

Re: [Pharo-dev] (a = b) ifTrue: []

[Max Leske]

> On 02 Apr 2015, at 17:31, Peter Uhnák  wrote:
> 
> >   ^ (a=b) ifTrue: [ aBlockCheckingConditions].
> 
> Boolean is still just an object, so you can use a cascade
> ^ (a=b)
> ifTrue: [ aBlockCheckingConditions];
> yourself

But that will always return the the boolean from the first statement! If you 
want to return something from the conditions block you can’t do that.

An alternative might be 

^ a = b and: [ condition ]

> 
> Peter

Re: [Pharo-dev] Can we have basicRaw in GTInspector?

[Andrei Chis]

Yes, we know about this slowness.
It comes from the auto-refresh feature.
Currently refreshing a tree presentation in Glamour is slow.
We tried to get it faster but I do not think we can do it until the release.

How many people do use this feature?
Should it be enabled by default?
We can add a toggle button in the inspector to enable/disable refresh, per
inspector window.



Cheers,
Andrei

On Thu, Apr 2, 2015 at 5:51 PM, Cyril Ferlicot 
wrote:

> Yeah.
> We was checking the CCMockConfiguration>>#mockProperty for Cocoon and if
> we go litteral4 -> 1 -> keyword
> here that freez a lot.
> And if you try to open something else you can put your image on the trash.
>
> On 2 April 2015 at 17:30, stepharo  wrote:
>
>> This morning GTInspector was so slow that it blocked the complete system
>> on the machine of Cyril. :(
>> We can tell him that he is stupid to have a bad machine or we could try
>> to use this to see how
>> we can help our users.
>>
>> So we had to use basicInspect to get our job done (once we ctrl-. to
>> escape the render hell)
>> because raw uses a tree morph.
>>
>> Why raw cannot reproduce the old simple and working basicInspect
>> then we could have a "basic" inspect on double click to avoid to use this
>> bad tree and that we can work.
>>
>> just try to on RubSmalltalkCodeMode class>>#menuOn: to get the feel. Even
>> on my superfast machine is
>> is sluggish.
>>
>> I really think that we should support backdoors.
>> We need to have a mini browser, a mini debugger and a working inspector.
>>
>> Setf
>>
>>
>
>
> --
> Cheers
> Cyril Ferlicot
>

Re: [Pharo-dev] (a = b) ifTrue: []

[Anne Etien]

Le 2 avr. 2015 à 18:02, Max Leske  a écrit :

> 
>> On 02 Apr 2015, at 17:31, Peter Uhnák  wrote:
>> 
>> >   ^ (a=b) ifTrue: [ aBlockCheckingConditions].
>> 
>> Boolean is still just an object, so you can use a cascade
>> ^ (a=b)
>> ifTrue: [ aBlockCheckingConditions];
>> yourself
> 
> But that will always return the the boolean from the first statement! If you 
> want to return something from the conditions block you can’t do that.
> 
> An alternative might be 
> 
> ^ a = b and: [ condition ]

Yes!! Good idea.
Thanks.
Anne
> 
>> 
>> Peter
> 

Re: [Pharo-dev] Can we have basicRaw in GTInspector?

[p...@highoctane.be]

Welcome to the club of GT is awesome and sometimes freezes it all.

Happened to me once or twice this morning as well.
Switched back to basic inspector for a couple things.

Having both options available would be nice (like inspect = basic /explore
= gt).

Phil

On Thu, Apr 2, 2015 at 5:30 PM, stepharo  wrote:

> This morning GTInspector was so slow that it blocked the complete system
> on the machine of Cyril. :(
> We can tell him that he is stupid to have a bad machine or we could try to
> use this to see how
> we can help our users.
>
> So we had to use basicInspect to get our job done (once we ctrl-. to
> escape the render hell)
> because raw uses a tree morph.
>
> Why raw cannot reproduce the old simple and working basicInspect
> then we could have a "basic" inspect on double click to avoid to use this
> bad tree and that we can work.
>
> just try to on RubSmalltalkCodeMode class>>#menuOn: to get the feel. Even
> on my superfast machine is
> is sluggish.
>
> I really think that we should support backdoors.
> We need to have a mini browser, a mini debugger and a working inspector.
>
> Setf
>
>

Re: [Pharo-dev] (a = b) ifTrue: []

[Peter Uhnák]

On Thu, Apr 2, 2015 at 6:02 PM, Max Leske  wrote:

>
> On 02 Apr 2015, at 17:31, Peter Uhnák  wrote:
>
> >   ^ (a=b) ifTrue: [ aBlockCheckingConditions].
>
>
> Boolean is still just an object, so you can use a cascade
> ^ (a=b)
> ifTrue: [ aBlockCheckingConditions];
> yourself
>
>
> But that will always return the the boolean from the first statement!
>
Ah, I've misread the question.

Peter

Re: [Pharo-dev] (a = b) ifTrue: []

[kilon alios]

its possible to completely or partly avoid a condition check . Instead you
can use a common name for a method for various objects , that method may
have different code for each object it belongs. This way you dont need to
check your data instead you send the message and you let the method itself
to execute the appropriate code for the approriate object( kind of data).

This also much more reasonable to read. It will depend however in your
particular situation. You can have also a chain of methods. Essentially we
talk here about objects that interact with each other by triggering methods
without the need for conditional checks since the method call is of the
same name but the code executed  depends on the receiver of the message /
messages.

It takes time to get used to this chain reaction message sending but I
think it really worth it because it produces far simpler code to read and
far more modular too.

On Thu, Apr 2, 2015 at 6:15 PM, Anne Etien 
wrote:

> Hi,
>
> I wanted to write a method that:
> - if (a = b) checks other conditions that are specified in the ifTrue
> block and return this (boolean) value
> - returns false if (a!=b)
>
> So I wrote:
> myMethod
> ^ (a=b) ifTrue: [ aBlockCheckingConditions].
>
> However, when (a!=b) the method returns nil (since false ifTrue: []
> returns nil). So do you have an idea how I can do to express that or should
> I mandatorily wrote also an ifFalse:?
>
> The problem comes certainly because we don’t know that the ifTrueBlock
> will return a boolean.
>
> If you have prettier ideas, I am interested in.
>
> Anne
>

Re: [Pharo-dev] (a = b) ifTrue: []

[Clément Bera]

Basically

ifTrue: aBlock

is equivalent to:

ifTrue: aBlock ifFalse: [ ]

This is why ifTrue: answers nil if the receiver is false, because the
evaluation of an empty block answers nil ( [ ] is the same thing as [ nil ]
).

So you have to write it explicitly. The #and: version is probably the best
:-).

2015-04-02 9:12 GMT-07:00 Anne Etien :

>
> Le 2 avr. 2015 à 18:02, Max Leske  a écrit :
>
>
> On 02 Apr 2015, at 17:31, Peter Uhnák  wrote:
>
> >   ^ (a=b) ifTrue: [ aBlockCheckingConditions].
>
>
> Boolean is still just an object, so you can use a cascade
> ^ (a=b)
> ifTrue: [ aBlockCheckingConditions];
> yourself
>
>
> But that will always return the the boolean from the first statement! If
> you want to return something from the conditions block you can’t do that.
>
> An alternative might be
>
> ^ a = b and: [ condition ]
>
>
> Yes!! Good idea.
> Thanks.
> Anne
>
>
>
> Peter
>
>
>
>

Re: [Pharo-dev] [Vm-dev] Re: Status of Pharo VM for FreeBSD

[Eliot Miranda]

Hi Andreas,

sorry to be late in replying.  This has been a busy month (I moved
house).

On Sat, Mar 14, 2015 at 10:33 AM, Andreas Wacknitz 
wrote:

>
> Hi Eliot,
>
> Am 11.03.2015 um 23:15 schrieb Eliot Miranda :
>
> HI Andreas,
>
> On Wed, Mar 11, 2015 at 9:55 AM, Andreas Wacknitz 
> wrote:
>
>>
>> Hi Clement,
>>
>> Am 11.03.2015 um 09:23 schrieb Clément Bera :
>>
>> Hello,
>>
>> About the FreeBSD VM, Holger Freyther worked on it so he's the best
>> person to answer. I think some people used it and it was at least partially
>> working.
>>
>> That’s my impression. The VMMaker contains some FreeBSD classes but I
>> have the impression that they are not complete (and probably outdated).
>>
>>
>> About your NativeBoost bug on openSolaris,  need more information:
>>
>> - Can you confirm that you use an intel processor on your openSolaris
>> machine ? I assume that yes but I ask because solaris were typically
>> running on other processors. NativeBoost, as of today, works only with
>> intel processor.
>>
>> Yes, my Sun Ultra 24 is an Intel based Workstation (Q9300).
>>
>> - Do you build the Cog VM or Stack VM ? I mean PharoVMBuild or
>> PharoSVMBuild ? I think the PharoSVMBuild does not include NativeBoost by
>> default, that may be your problem. There's a fix somewhere...
>>
>> PharoVM from "branch 'master' of
>> https://github.com/pharo-project/pharo-vm"; (thus Cog VM).
>>
>
> I would like to fold back any changes into the svn master repository for
> Cog.   What are the diffs?  (If you have time to send me the diffs that
> would save me a lot of time).
>
> I don’t know whether there is much to harvest from what I did. As far as I
> remember most of my work was hacking the generator image created by the
> pharo vm scripts (for my Mac) in order to make
> the resulting C code to compile under openindiana. The basis for Solaris
> was already there (and as far as I can see it is also in the Squeak VM
> sources). I only tweaked some definitions and includes.
> I will look at my notes tomorrow and will post if I will find something
> relevant.
>
> I am curios about the future of the PharoVM. The main development of the
> VM seem to happen in the SqueakVM (by you). Getting the Spur changes into
> the PharoVM seem to be a lot of work.
>

Note that this will happen (or is already happening).  Esteban is working
on building the Spur version of Pharo, so he is doing this work.  But
actually it *isn't* that much work.  There is basically a trio of new
memory management files for each platform, e.g.
platforms/unix/vm/sqUnixSpurMemory.c, and a new source tree for the spur
vm, spursrc/vm.  The system is already set up to build multiple VMs (at
least the svn tree is).



> Wouldn’t it be better to move back the changes of the PharoVM into the
> SqueakVM and have a united development?
>

Well, I don't think the Pharo community will be willing to move to svn.
SOme time I may be able to move to git.  But yes, I *would* like to see
important fixes merged back into the SqueakVM.  I think this is very
important.  I'm too overloaded to look at the pharovm so I'm dependent on
those working on the pharovm in giut to send me changes for integration.


And what is the status and what are the plans regarding Timothy’s
> (gettimothy) work?
>
> Regards
> Andreas
>
>
>


-- 
best,
Eliot

[Pharo-dev] Failing VM tests

[Nicolai Hess]

Anyone knows why the vm tests on the build server are failing?

https://ci.inria.fr/pharo/view/4.0-VM/job/PharoVM-tests/lastCompletedBuild/testReport/

is this importan?


nicolai

Re: [Pharo-dev] Can we have basicRaw in GTInspector?

[Tudor Girba]

The Playground has inspect on Cmd+Shift+i as requested by you.

There is a problem with the update as it does not scale in the current
form. Please see the reply of Andrei. We will likely remove that feature
for the release.

Just to clarify: When did we ever say that someone is stupid?

Cheers,
Doru



On Thu, Apr 2, 2015 at 5:30 PM, stepharo  wrote:

> This morning GTInspector was so slow that it blocked the complete system
> on the machine of Cyril. :(
> We can tell him that he is stupid to have a bad machine or we could try to
> use this to see how
> we can help our users.
>
> So we had to use basicInspect to get our job done (once we ctrl-. to
> escape the render hell)
> because raw uses a tree morph.
>
> Why raw cannot reproduce the old simple and working basicInspect
> then we could have a "basic" inspect on double click to avoid to use this
> bad tree and that we can work.
>
> just try to on RubSmalltalkCodeMode class>>#menuOn: to get the feel. Even
> on my superfast machine is
> is sluggish.
>
> I really think that we should support backdoors.
> We need to have a mini browser, a mini debugger and a working inspector.
>
> Setf
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] Can we have basicRaw in GTInspector?

[Tudor Girba]

Hi Phil,

I think this is just not constructive at all to have a private club like
that and not tell us about it.

Please take a look at the reply of Andrei.

Cheers,
Doru



On Thu, Apr 2, 2015 at 6:16 PM, p...@highoctane.be 
wrote:

> Welcome to the club of GT is awesome and sometimes freezes it all.
>
> Happened to me once or twice this morning as well.
> Switched back to basic inspector for a couple things.
>
> Having both options available would be nice (like inspect = basic /explore
> = gt).
>
> Phil
>
> On Thu, Apr 2, 2015 at 5:30 PM, stepharo  wrote:
>
>> This morning GTInspector was so slow that it blocked the complete system
>> on the machine of Cyril. :(
>> We can tell him that he is stupid to have a bad machine or we could try
>> to use this to see how
>> we can help our users.
>>
>> So we had to use basicInspect to get our job done (once we ctrl-. to
>> escape the render hell)
>> because raw uses a tree morph.
>>
>> Why raw cannot reproduce the old simple and working basicInspect
>> then we could have a "basic" inspect on double click to avoid to use this
>> bad tree and that we can work.
>>
>> just try to on RubSmalltalkCodeMode class>>#menuOn: to get the feel. Even
>> on my superfast machine is
>> is sluggish.
>>
>> I really think that we should support backdoors.
>> We need to have a mini browser, a mini debugger and a working inspector.
>>
>> Setf
>>
>>
>
>
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] Playground opening issue

[Tudor Girba]

This is a fun one. I will take a look.

Cheers,
Doru

On Thu, Apr 2, 2015 at 3:31 PM, Franck Warlouzet <
franck.warlou...@hotmail.fr> wrote:

> I opened a Fogbugz entry :
>
> https://pharo.fogbugz.com/f/cases/15281/Playground-opening-issue
>
> --
> From: franck.warlou...@hotmail.fr
> To: pharo-dev@lists.pharo.org
> Date: Thu, 2 Apr 2015 15:26:31 +0200
> Subject: [Pharo-dev] Playground opening issue
>
>
> Hello,
>
> Open a new Playground when one of the others is already opened is ok, but
> if all of the Playgrounds are minimalized, the new one will be opened very
> very small (Too small to be used).
>
> Cheers,
> Franck
>



-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] Playground opening issue

[Tudor Girba]

Ok. A fix is committed:

Name: GT-Playground-TudorGirba.102
Author: TudorGirba
Time: 2 April 2015, 9:32:45.226868 pm
UUID: 4f8af56e-4904-443d-8e04-2d4e464efc22
Ancestors: GT-Playground-AndreiChis.101

15281 Playground opening issue

do not react on minimization


Cheers,
Doru


On Thu, Apr 2, 2015 at 9:28 PM, Tudor Girba  wrote:

> This is a fun one. I will take a look.
>
> Cheers,
> Doru
>
> On Thu, Apr 2, 2015 at 3:31 PM, Franck Warlouzet <
> franck.warlou...@hotmail.fr> wrote:
>
>> I opened a Fogbugz entry :
>>
>> https://pharo.fogbugz.com/f/cases/15281/Playground-opening-issue
>>
>> --
>> From: franck.warlou...@hotmail.fr
>> To: pharo-dev@lists.pharo.org
>> Date: Thu, 2 Apr 2015 15:26:31 +0200
>> Subject: [Pharo-dev] Playground opening issue
>>
>>
>> Hello,
>>
>> Open a new Playground when one of the others is already opened is ok, but
>> if all of the Playgrounds are minimalized, the new one will be opened very
>> very small (Too small to be used).
>>
>> Cheers,
>> Franck
>>
>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>



-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] Can we have basicRaw in GTInspector?

[p...@highoctane.be]

On Thu, Apr 2, 2015 at 9:26 PM, Tudor Girba  wrote:

> Hi Phil,
>
> I think this is just not constructive at all to have a private club like
> that and not tell us about it.
>
> Please take a look at the reply of Andrei.
>

I am on 3.0 and there is for sure a ton of fixes in 4.0 already.
So, I have to live with what I do have there (e.g. No Spotter yet).

Need to vent after having a couple of image freezes when under pressure.

Nothing to worry about.

Phil

>
> Cheers,
> Doru
>
>
>
> On Thu, Apr 2, 2015 at 6:16 PM, p...@highoctane.be 
> wrote:
>
>> Welcome to the club of GT is awesome and sometimes freezes it all.
>>
>> Happened to me once or twice this morning as well.
>> Switched back to basic inspector for a couple things.
>>
>> Having both options available would be nice (like inspect = basic
>> /explore = gt).
>>
>> Phil
>>
>> On Thu, Apr 2, 2015 at 5:30 PM, stepharo  wrote:
>>
>>> This morning GTInspector was so slow that it blocked the complete system
>>> on the machine of Cyril. :(
>>> We can tell him that he is stupid to have a bad machine or we could try
>>> to use this to see how
>>> we can help our users.
>>>
>>> So we had to use basicInspect to get our job done (once we ctrl-. to
>>> escape the render hell)
>>> because raw uses a tree morph.
>>>
>>> Why raw cannot reproduce the old simple and working basicInspect
>>> then we could have a "basic" inspect on double click to avoid to use
>>> this bad tree and that we can work.
>>>
>>> just try to on RubSmalltalkCodeMode class>>#menuOn: to get the feel.
>>> Even on my superfast machine is
>>> is sluggish.
>>>
>>> I really think that we should support backdoors.
>>> We need to have a mini browser, a mini debugger and a working inspector.
>>>
>>> Setf
>>>
>>>
>>
>>
>>
>>
>>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>

Re: [Pharo-dev] Playground opening issue

[Franck Warlouzet]

Nice it works, thank you !

Cheers,
Franck

Date: Thu, 2 Apr 2015 21:34:11 +0200
From: tu...@tudorgirba.com
To: pharo-dev@lists.pharo.org
Subject: Re: [Pharo-dev] Playground opening issue

Ok. A fix is committed:
Name: GT-Playground-TudorGirba.102Author: TudorGirbaTime: 2 April 2015, 
9:32:45.226868 pmUUID: 4f8af56e-4904-443d-8e04-2d4e464efc22Ancestors: 
GT-Playground-AndreiChis.101
15281 Playground opening issue
do not react on minimization

Cheers,Doru

On Thu, Apr 2, 2015 at 9:28 PM, Tudor Girba  wrote:
This is a fun one. I will take a look.
Cheers,Doru
On Thu, Apr 2, 2015 at 3:31 PM, Franck Warlouzet  
wrote:



I opened a Fogbugz entry :

https://pharo.fogbugz.com/f/cases/15281/Playground-opening-issue

From: franck.warlou...@hotmail.fr
To: pharo-dev@lists.pharo.org
Date: Thu, 2 Apr 2015 15:26:31 +0200
Subject: [Pharo-dev] Playground opening issue




Hello,

Open a new Playground when one of the others is already opened is ok, but if 
all of the Playgrounds are minimalized, the new one will be opened very very 
small (Too small to be used).

Cheers,
Franck

  


-- 
www.tudorgirba.com
"Every thing has its own flow"



-- 
www.tudorgirba.com
"Every thing has its own flow"
  

Re: [Pharo-dev] Failing VM tests

[Clément Bera]

Probably the last merge from Eliot branch introduced bugs. Only latest VM
is bugged, not stable. Maybe it's a bug on Eliot's branch that will be
fixed soon by him, maybe it's a merge bug.

Depends on what you call important.

2015-04-02 12:14 GMT-07:00 Nicolai Hess :

> Anyone knows why the vm tests on the build server are failing?
>
>
> https://ci.inria.fr/pharo/view/4.0-VM/job/PharoVM-tests/lastCompletedBuild/testReport/
>
> is this importan?
>
>
> nicolai
>

Re: [Pharo-dev] Playground opening issue

[Jigyasa Grover]

Hi !
It works for me too :)
I checked it in Pharo4.0 (Latest update: #40592)
Thanks

On Fri, Apr 3, 2015 at 1:30 AM, Franck Warlouzet <
franck.warlou...@hotmail.fr> wrote:

> Nice it works, thank you !
>
> Cheers,
> Franck
>
> --
> Date: Thu, 2 Apr 2015 21:34:11 +0200
> From: tu...@tudorgirba.com
> To: pharo-dev@lists.pharo.org
> Subject: Re: [Pharo-dev] Playground opening issue
>
>
> Ok. A fix is committed:
>
> Name: GT-Playground-TudorGirba.102
> Author: TudorGirba
> Time: 2 April 2015, 9:32:45.226868 pm
> UUID: 4f8af56e-4904-443d-8e04-2d4e464efc22
> Ancestors: GT-Playground-AndreiChis.101
>
> 15281 Playground opening issue
>
> do not react on minimization
>
>
> Cheers,
> Doru
>
>
> On Thu, Apr 2, 2015 at 9:28 PM, Tudor Girba  wrote:
>
> This is a fun one. I will take a look.
>
> Cheers,
> Doru
>
> On Thu, Apr 2, 2015 at 3:31 PM, Franck Warlouzet <
> franck.warlou...@hotmail.fr> wrote:
>
> I opened a Fogbugz entry :
>
> https://pharo.fogbugz.com/f/cases/15281/Playground-opening-issue
>
> --
> From: franck.warlou...@hotmail.fr
> To: pharo-dev@lists.pharo.org
> Date: Thu, 2 Apr 2015 15:26:31 +0200
> Subject: [Pharo-dev] Playground opening issue
>
>
> Hello,
>
> Open a new Playground when one of the others is already opened is ok, but
> if all of the Playgrounds are minimalized, the new one will be opened very
> very small (Too small to be used).
>
> Cheers,
> Franck
>
>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>
>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>

Re: [Pharo-dev] FileUrl: Removal Rationale

[Sven Van Caekenberghe]

Hi Sean,

You are right that ZnUrl unifies all schemes in one object class.

Something called ZnUrlOperation exists and is used to dispatch named operations 
on multiple conditions, the scheme, some arguments, but potentially any aspect 
of a URL.

Having subclasses for each scheme is hard to maintain (there are hundreds of 
schemes) and is only one dimension of looking at URLs. It also makes little 
sense implementation wise.

The #asFileReference implementation does indeed have a hard test inside it, but 
it is in essence correct: you can only do the conversion is that particular 
case.

I am not saying that the way things are today is the final answer to URL 
implementation, maybe things can be improved. But what we have now covers a lot 
of ground (usage scenarios).

BTW, Xtreams' #reading, #writing & #appending could also make sense for 
non-file URLs ...

Sven

> On 01 Apr 2015, at 04:19, Sean P. DeNigris  wrote:
> 
> I guess FileUrl has been subsumed by ZnUrl. The problem is that the fact that
> a URL points to a file is part of it's type. Now there is the ugly:
>  ZnUrl>>#asFileReference
>   ...
>   self assert: self scheme = #file description: 'Only a file:// URL can be
> converted to a FileReference'.
> 
> Also Xtreams had FileUrl #reading, #writing, #appending, which also don't
> make sense in their current implementations for non-file URLs.
> 
> Suggestions? Comments?
> 
> 
> 
> -
> Cheers,
> Sean
> --
> View this message in context: 
> http://forum.world.st/FileUrl-Removal-Rationale-tp4816536.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
> 

Re: [Pharo-dev] Bloc Roadmap

[Sean P. DeNigris]

> if you can collect the answers to your question and put them into the pillar 
> doc :), this can help.
Aww… you guessed my plan ;)





-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Bloc-Roadmap-tp4816171p4817050.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] FileUrl: Removal Rationale

[Sean P. DeNigris]

Sven Van Caekenberghe-2 wrote
> Having subclasses for each scheme is hard to maintain (there are hundreds
> of schemes)... It also makes little sense implementation wise.

I’m not understanding. For one thing, in Core, we’re not interested in all
of the hundreds of schemes but just the few most common (http, file) -
although users interested in the specifics of other schemes could easily add
those subclasses in their apps. Since subclassing is just a way to share
code, wouldn’t a ZnFileUrl merely consist of exactly the methods we’re
talking about - but more simply implemented? For one thing, it seems it
would make extension easier. If I wanted to handle FileUrls and HttpUrls
polymorphically with separate classes, no problem - implement two methods.
But as it is now, IIUC I have to either implement two operation classes or
have a method with a budding switch statement. Also, IMHO implementing a
custom multiple dispatch seems exotic enough (i.e. takes extra effort to
understand) to require a large benefit to justify.

My 2c



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/FileUrl-Removal-Rationale-tp4816536p4817064.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.