On Tue, Aug 30, 2011 at 8:42 AM, Stéphane Ducasse wrote:
>
> On Aug 30, 2011, at 8:37 AM, Pat Maddox wrote:
>
> > 1.2 is for download on the site, 1.3 is listed on the site with no links,
> and 1.4 is discussed on the mailing list. I have absolutely no idea what is
> going on with Pharo, which ve
On Aug 29, 2011, at 10:38 PM, Lukas Renggli wrote:
Is the current system simple and minimal?
>>>
>>> No, it is complex and it is getting bigger with every release.
>>
>> No, i wouldn't say so.
>>
>> Most fixes and improvements are still about cleaning things out and fixing
>> bugs.
>> Bu
In my point of view, most people in the community wants a micro kernel
for Pharo (or better no kernel at all) on top of which it would be
possible to load packages such as a graphical interface, browsers, a
network library... I see two ways to achieve this goal.
1) The immediate unloading way. In
On Aug 30, 2011, at 8:37 AM, Pat Maddox wrote:
> 1.2 is for download on the site, 1.3 is listed on the site with no links, and
> 1.4 is discussed on the mailing list. I have absolutely no idea what is going
> on with Pharo, which version is being actively developed and maintained,
> which one
>
>> Hi guys,
>>
>> I am completely for inventing something new.
>>
>> However, I do not think this is the right model for doing so.
>> In a sense we are getting static, we put some tools in the image and
>> expect people to use them.
>> I think that this is going to be contra productive.
>> I b
Igor
I was thinking about it yesterday
do you have the vms?
Marcus and others do we introduce the fix for the 'broken' syntax highlight
because it touches a lot of code?
and this is really late in the process and this is not a showstopper.
Stef
On Aug 30, 2011, at 8:31 AM, Marcus Denker wro
1.2 is for download on the site, 1.3 is listed on the site with no links, and
1.4 is discussed on the mailing list. I have absolutely no idea what is going
on with Pharo, which version is being actively developed and maintained, which
one to use, etc. It is very frustrating. So what's the deal w
On Aug 29, 2011, at 10:56 PM, Sven Van Caekenberghe wrote:
> Lukas,
>
> On 29 Aug 2011, at 19:53, Lukas Renggli wrote:
>
>> I disagree; I would like a small and stable Pharo in which crazy ideas
>> can be realized. For that I don't need fancy abstractions, but a
>> minimal, simple and absolutel
On Aug 30, 2011, at 1:58 AM, Douglas Brebner wrote:
> On 29/08/2011 21:41, Stéphane Ducasse wrote:
>> So may be you do not like Ring and this is ok.
>> Now I want an abstraction so that we can build a remote browser by plugging
>> simply rTalk + nautilus + ring.
>> With the current state of the
On Aug 29, 2011, at 10:56 PM, Jorge Ressia wrote:
> Hi guys,
>
> I am completely for inventing something new.
>
> However, I do not think this is the right model for doing so.
> In a sense we are getting static, we put some tools in the image and
> expect people to use them.
> I think that this
On Tue, Aug 30, 2011 at 8:31 AM, Marcus Denker wrote:
> So maybe we should just release with the same VMs as 1.2, just to get it done?
What is the problem with the 1.2 VM that doesn't make it a good
candidate for 1.3 ?
--
Damien Cassou
http://damiencassou.seasidehosting.st
"Lambdas are relegat
at least we should get this list studied and we decide.
we shoudl open a bug entry.
On Aug 30, 2011, at 1:34 AM, Sean P. DeNigris wrote:
> Are pre-1.3 deprecated methods purposely put into protocol *deprecated13?
>
> For example:
> String>>asDefaultDecodedString on: 2/13/2010 in: 1.1
> Pluggable
On Aug 30, 2011, at 1:35 AM, Sean P. DeNigris wrote:
> Are pre-1.3 deprecated methods purposely put into protocol *deprecated13?
>
> For example:
> String>>asDefaultDecodedString on: 2/13/2010 in: 1.1
> PluggableTextMorph>>setTextColor: on: 8/17/2010 in: 1.2
> SequencableCollection>>sortBy: on:
On Aug 30, 2011, at 1:43 AM, Sean P. DeNigris wrote:
> Also the date formats are inconsistent e.g. '8/29/2011' vs. '29 August,
> 2011'. Does it matter?
not really right now. but ok to live with it.
Now it would be good to have a refactoring to deprecate a method (but I had no
time and know how
On Aug 30, 2011, at 1:44 AM, Sean P. DeNigris wrote:
> Also the date formats are inconsistent e.g. '8/29/2011' vs. '29 August,
> 2011'. Does it matter?
No
>
> --
> View this message in context:
> http://forum.world.st/Deprecation-policy-tp3777647p3777671.html
> Sent from the Pharo Smalltalk m
On Aug 30, 2011, at 1:23 AM, Sean P. DeNigris wrote:
> I want to add a comment to #deprecated:on:in:
>
> This is my understanding (it is implemented inconsistently in 1.4 update
> #14112):
>
> For methods:
> 1. Have the method call deprecated:on:in: as its first step
> - the versionString shou
The state is the same as 3 week ago, (and I fear the same as in 3 weeks):
-> image is finished, there are some (5 or so bugreport) that will be
integrated as they get fixed,
but this does not hold up the release
-> What is missing are VMs and the one-click. I do not
On Mon, Aug 29, 2011 at 10:25 PM, Nicolas Anquetil
wrote:
> Should I remove this?
it looks like that if you remove "aBlock value: self", aBlock will
never get executed. The question is now "does the name #allElementsDo:
makes sense with this behavior?" I don't think so. One way to fix it
is to mo
Indeed, it should be named withAllElementsDo: to be consistent with Smalltalk
naming, and then it would exactly what the name says :)
Doru
On 30 Aug 2011, at 07:51, Max Leske wrote:
> … and maybe it should be renamed to #withAllElementsDo: ?
>
>
> On 30.08.2011, at 00:01, Levente Uzonyi wrot
… and maybe it should be renamed to #withAllElementsDo: ?
On 30.08.2011, at 00:01, Levente Uzonyi wrote:
> On Mon, 29 Aug 2011, Nicolas Anquetil wrote:
>
>> In XML-Parser-Nodes we have:
>>
>> XMLNodeWithElements
>> XMLDocument
>> XMLElement
>>
>> A document is composed of elements that can ho
Hi,
maybe I haven't read correctly the mailing-list but I still don't know if
Pharo 1.3 is released or not, cannot find any official announcement, release
date
The website is misleading, I can help on this, but need to be sure.
I've also prepared a french announcement but needs to be up to
Hi,
I got network sockets to work in my Android port of CogVM with
PharoCore-13137 image.
I made changes to the logic of aioPoll so that it just checks on all
handles once and returns if no I/O operations are ready without any
looping, otherwise calls all relevant I/O handlers and returns.
aioPol
On 30 August 2011 02:58, Douglas Brebner wrote:
> On 29/08/2011 21:41, Stéphane Ducasse wrote:
>>
>> So may be you do not like Ring and this is ok.
>> Now I want an abstraction so that we can build a remote browser by
>> plugging simply rTalk + nautilus + ring.
>> With the current state of the sys
Am 2011-08-29 um 08:18 schrieb Alexander Lazarević:
> 2011/8/27 Bert Freudenberg
> The Chile mirror is up.
>
> Just learned about that one. Thanks!
>
> While it seems more stable indeed, it also gets much less traffic. I'n not
> sure it would handle the load of squeaksource.com as well.
>
>
On 29/08/2011 21:41, Stéphane Ducasse wrote:
So may be you do not like Ring and this is ok.
Now I want an abstraction so that we can build a remote browser by plugging
simply rTalk + nautilus + ring.
With the current state of the system this was simply impossible.
I want to be able to browse se
Also the date formats are inconsistent e.g. '8/29/2011' vs. '29 August,
2011'. Does it matter?
--
View this message in context:
http://forum.world.st/Deprecation-policy-tp3777647p3777671.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Are pre-1.3 deprecated methods purposely put into protocol *deprecated13?
For example:
String>>asDefaultDecodedString on: 2/13/2010 in: 1.1
PluggableTextMorph>>setTextColor: on: 8/17/2010 in: 1.2
SequencableCollection>>sortBy: on: 9/4/2010 in: 1.2
SystemDictionary>>hasSpecialSelector:ifTrueSetByte
I want to add a comment to #deprecated:on:in:
This is my understanding (it is implemented inconsistently in 1.4 update
#14112):
For methods:
1. Have the method call deprecated:on:in: as its first step
- the versionString should be e.g. 'Pharo1.4' (although I found #Pharo1.4,
see the problem; an
On Mon, 29 Aug 2011, Nicolas Anquetil wrote:
In XML-Parser-Nodes we have:
XMLNodeWithElements
XMLDocument
XMLElement
A document is composed of elements that can hold recursively other elements
XMLNodeWithElements implements (in protocol enumerating)
allElementsDo: aBlock
"Descend depth-first
does it make sense to have to have WeakMessageSend not been reentrant?
Because we could merge
WeakMessageSend and NonRentrantWeakMessageSend.
Or we could move the two subclasses of WekMessageSend to the same package as
WeakMessageSend
or alternate solution.
Rename Polymorph-EventEnhancem
14112
-
- Issue 4550: methodSymbol is a bad name for selector.
http://code.google.com/p/pharo/issues/detail?id=4550
- Issue 4711: Pharo 1.4 has wrong link to inbox. Thanks Sean De Nigris.
http://code.google.com/p/pharo/issues/detail?id=4711
- Issue 4710: Incorrect comme
On Aug 29, 2011, at 11:13 PM, Hernán Morales Durand wrote:
> Hi Stef,
>
> I just want to know if OB will be supported in Pharo >= 1.4 even if
> you don't maintain it, because I've spent energy and time learning the
> framework, and I have written one developer guide for OB and I have
> planned a
Hi Stef,
I just want to know if OB will be supported in Pharo >= 1.4 even if
you don't maintain it, because I've spent energy and time learning the
framework, and I have written one developer guide for OB and I have
planned at least 5 more browsers.
2011/8/28 Stéphane Ducasse :
>
> On Aug 28, 201
Hi guys,
I am completely for inventing something new.
However, I do not think this is the right model for doing so.
In a sense we are getting static, we put some tools in the image and
expect people to use them.
I think that this is going to be contra productive.
I believe that a much better mode
Lukas,
On 29 Aug 2011, at 19:53, Lukas Renggli wrote:
> I disagree; I would like a small and stable Pharo in which crazy ideas
> can be realized. For that I don't need fancy abstractions, but a
> minimal, simple and absolutely stable system in which I can load and
> do whatever I want. Maybe this
>>
>
> Zinc is an excellent example, because it is fully backward compatible.
> I don't see that with RPackage, SystemAnnouncements, Ring, Shout
> (before Alan fixed it), with the proposed RB changes, ...
I do not understand how SystemAnnouncements could be fully backward compatible,
then and th
On Aug 29, 2011, at 10:37 PM, Lukas Renggli wrote:
Is the current system simple and minimal?
>>>
>>> No, it is complex and it is getting bigger with every release.
>>
>> No, i wouldn't say so.
>>
>> Most fixes and improvements are still about cleaning things out and fixing
>> bugs.
>> Bu
Is the current system simple and minimal?
>>>
>>> No, it is complex and it is getting bigger with every release.
>>>
Do you think the Pharo we have is good enough to have a future?
>>>
>>> No, there is a lot to be improved. I think the future of Pharo is what
>>> can be built on top, n
>>> Is the current system simple and minimal?
>>
>> No, it is complex and it is getting bigger with every release.
>
> No, i wouldn't say so.
>
> Most fixes and improvements are still about cleaning things out and fixing
> bugs.
> But not about new features.
Yes, you are right. In fact Pharo 1.4
In XML-Parser-Nodes we have:
XMLNodeWithElements
XMLDocument
XMLElement
A document is composed of elements that can hold recursively other elements
XMLNodeWithElements implements (in protocol enumerating)
allElementsDo: aBlock
"Descend depth-first visiting each element with aBlock."
sel
> I really do not understand where this feeling of bloating comes from. Perhaps
> it is from the fact that for a transitional period, we will have a couple of
> systems in parallel. But, this is necessary to move things forward and to
> have a smooth transition:
> - The Announcements will replac
Look at Scanner reference to get a feel! I do not call that simple, stable at
all.
Stef
>
>
>
> No more for me.
Introducing more code into Pharo that depends on more parts of Pharo
(RPackage, Announcement, Pragma, Ring, RB, Shout, ...) doesn't make it
easier to mainta
14111
-
- Issue 4609: Syntax highlighting broken. Thanks Alain Plantec and
Benjmain van Ryseghem
On 29 August 2011 19:47, Lukas Renggli wrote:
>> No more for me.
>
> Introducing more code into Pharo that depends on more parts of Pharo
> (RPackage, Announcement, Pragma, Ring, RB, Shout, ...) doesn't make it
> easier to maintain and change Pharo. Or did I misunderstand somet
sounds great.
Stef
On Aug 29, 2011, at 7:30 PM, Sean P. DeNigris wrote:
> Thanks to Stephan Eggermont who paired with me all morning on this.
>
> Here are the results of the first pass in inbox
> (SLICE-Issue-2394-Halt-SeanDeNigris.1):
>
> Object
> * 16 methods deprecated
> * 5 halt methods th
On Aug 29, 2011, at 9:08 PM, Lukas Renggli wrote:
Is the current system simple and minimal?
>>>
>>> No, it is complex and it is getting bigger with every release.
>>>
Do you think the Pharo we have is good enough to have a future?
>>>
>>> No, there is a lot to be improved. I think th
Hi,
On 29 Aug 2011, at 21:03, Marcus Denker wrote:
>
> On Aug 29, 2011, at 8:55 PM, Marcus Denker wrote:
>
>>
>> On Aug 29, 2011, at 8:47 PM, Lukas Renggli wrote:
Is the current system simple and minimal?
>>>
>>> No, it is complex and it is getting bigger with every release.
>
> T
>>> Is the current system simple and minimal?
>>
>> No, it is complex and it is getting bigger with every release.
>>
>>> Do you think the Pharo we have is good enough to have a future?
>>
>> No, there is a lot to be improved. I think the future of Pharo is what
>> can be built on top, not what can
On Aug 29, 2011, at 8:55 PM, Marcus Denker wrote:
>
> On Aug 29, 2011, at 8:47 PM, Lukas Renggli wrote:
>>>
>>> Is the current system simple and minimal?
>>
>> No, it is complex and it is getting bigger with every release.
The size of the image is Monticello Meta Data and ScriptLoader.
Just
Sean P. DeNigris wrote:
>
> p.s. guys, please start another thread. Many people may find this
> interesting and it has nothing to do with the OP.
>
Or not.
--
View this message in context:
http://forum.world.st/Omnibrowser-in-1-4-tp3774180p3777074.html
Sent from the Pharo Smalltalk mailing li
On Aug 29, 2011, at 8:47 PM, Lukas Renggli wrote:
>>
>> Is the current system simple and minimal?
>
> No, it is complex and it is getting bigger with every release.
>
>> Do you think the Pharo we have is good enough to have a future?
>
> No, there is a lot to be improved. I think the future of
> No more for me.
Introducing more code into Pharo that depends on more parts of Pharo
(RPackage, Announcement, Pragma, Ring, RB, Shout, ...) doesn't make it
easier to maintain and change Pharo. Or did I misunderstand something
about cohesion and coupling? :-)
>>>
>>> W
Sean P. DeNigris wrote:
>
> Does anyone have OB working in 1.4?
>
Until we get things sorted out, I got OmniBrowser to load with only one
small change, tested a change method name refactoring, and 1361 out of 1365
tests pass.
1. ConfigurationOfOmniBrowser project bleedingEdge load: 'Dev'.
2. F
On Aug 29, 2011, at 7:54 PM, Lukas Renggli wrote:
No more for me.
>>>
>>> Introducing more code into Pharo that depends on more parts of Pharo
>>> (RPackage, Announcement, Pragma, Ring, RB, Shout, ...) doesn't make it
>>> easier to maintain and change Pharo. Or did I misunderstand something
On Aug 29, 2011, at 7:19 PM, Alexandre Bergel wrote:
> RoelTyper is probably what should be interfaced with the automatic completion.
it is.
Stef
> Other approaches are expensive.
>
> Alexandre
>
>
>
> On 28 Aug 2011, at 19:04, Frank Shearar wrote:
>
>> On 28 August 2011 21:18, Sean P. De
>>> No more for me.
>>
>> Introducing more code into Pharo that depends on more parts of Pharo
>> (RPackage, Announcement, Pragma, Ring, RB, Shout, ...) doesn't make it
>> easier to maintain and change Pharo. Or did I misunderstand something
>> about cohesion and coupling? :-)
>
> With that philoso
On Aug 29, 2011, at 6:35 PM, Lukas Renggli wrote:
>>> Nautilus looks to me like yet another Smalltalk-80 browser that works
>>> exactly the same as all previous Smalltalk browsers in the last 32
>>> years (including OB). IMHO fixed lists, a text field and ugly buttons
>>> do not cut it anymore. D
cool!
Alexandre
On 29 Aug 2011, at 14:30, Sean P. DeNigris wrote:
> Thanks to Stephan Eggermont who paired with me all morning on this.
>
> Here are the results of the first pass in inbox
> (SLICE-Issue-2394-Halt-SeanDeNigris.1):
>
> Object
> * 16 methods deprecated
> * 5 halt methods that no
Thanks to Stephan Eggermont who paired with me all morning on this.
Here are the results of the first pass in inbox
(SLICE-Issue-2394-Halt-SeanDeNigris.1):
Object
* 16 methods deprecated
* 5 halt methods that now forward to Halt
Globals - can remove #HaltOnce and #HaltCount (I don't know how)
H
RoelTyper is probably what should be interfaced with the automatic completion.
Other approaches are expensive.
Alexandre
On 28 Aug 2011, at 19:04, Frank Shearar wrote:
> On 28 August 2011 21:18, Sean P. DeNigris wrote:
>>
>> Damien Cassou wrote:
>>>
>>>
>>
>> Cool! That would make a big d
On Mon, Aug 29, 2011 at 6:35 PM, Lukas Renggli wrote:
> Or did I misunderstand something
> about cohesion and coupling? :-)
you certainly got a bad teacher ;-)
--
Damien Cassou
http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until Java makes them
popular by n
On Aug 29, 2011, at 6:35 PM, Lukas Renggli wrote:
>>> Nautilus looks to me like yet another Smalltalk-80 browser that works
>>> exactly the same as all previous Smalltalk browsers in the last 32
>>> years (including OB). IMHO fixed lists, a text field and ugly buttons
>>> do not cut it anymore. D
>> Nautilus looks to me like yet another Smalltalk-80 browser that works
>> exactly the same as all previous Smalltalk browsers in the last 32
>> years (including OB). IMHO fixed lists, a text field and ugly buttons
>> do not cut it anymore. Did any Smalltalker ever work with XCode,
>> Eclipse, Vis
> * Halt onCount: - this is a weird one
I would remove it. I have never seen anybody using it.
> * Is anybody using Object>>toggleHaltOnce? I'm toying with removing it as
> there are no senders in the image, and there are accessors and a testing
> method
That was probably there to call it from a
On Mon, Aug 29, 2011 at 5:44 PM, Sean P. DeNigris wrote:
> * Is anybody using Object>>toggleHaltOnce? I'm toying with removing it as
> there are no senders in the image, and there are accessors and a testing
> method
I guess there are no senders because a developer calls this method
from a worksp
Sean P. DeNigris wrote:
>
> Here are a few points and questions...
>
Forgot one thing. #haltOnCount: currently depends on whether haltOnce is
enabled. In my world, the purpose of haltOnce is so that you can put a halt
down deep in the system where otherwise it may fire over and over (e.g. in
th
Okay, I'm mostly through the refactoring. It is sooo much cleaner out of
object. Many deprecated methods!! Here are a few points and questions...
* Under protest :) I'm keeping the Object API, which forwards to Halt.
* I was slightly liberated to find that halt behavior is not part of the
ANSI sta
Yeah, I also do have several images that have been running for months
without crashing, that's what's bugging me :)
This is an Iliad app, I'll check both how I overrode the session class and
the VNC connection to see if I can get closer to where the problem comes
from.
Thanks!
Bernat.
2011/8/29
+ 1000
now who has time.
So nautilus is our attempt to make sure that we can still have a browser and
remove
string holder out of the image.
Now the only person I see being real and making progress on the IDE front is
doru with glamour.
Now Nautilus is not in competition with OB or Glamour. It
On Mon, Aug 29, 2011 at 2:51 PM, Torsten Bergmann wrote:
> The only thing I miss in these Java browsers is method categorization
> and I still hate scrolling in long *.java files ;)
press CTRL+o in Eclipse to get a list of methods of the current class,
CTRL+o again to also get the methods of the
>
>> Since there is ob, I personally use Nautilus. It provides interesting
>> functionalities
>> such as grouping packages and the hierarchies view (such as in vw). Importing
>> things are missing however, including refactorings.
>
> Personally I wonder what the goal of Nautilus is?
>
> Nautilu
On Aug 29, 2011, at 2:22 PM, Lukas Renggli wrote:
>>> I do not know. I will continue to use OB.
>>
>> Lukas, if you get a version working in 1.4, will you let me know/release it?
>
> It took several man-weeks to get everything running in Pharo 1.3 and
> there are still quite a few of issues lef
+1
On Mon, Aug 29, 2011 at 3:26 PM, Max Leske wrote:
> +1
>
> On 29.08.2011, at 14:51, Torsten Bergmann wrote:
>
> Yes, there were times when other IDE's got their ideas from
> Smalltalk and I think now we should look at some ideas from
> mainstream IDE's.
>
--
Jorge Ressia
www.jorgeressia.co
+1
On 29.08.2011, at 14:51, Torsten Bergmann wrote:
> Yes, there were times when other IDE's got their ideas from
> Smalltalk and I think now we should look at some ideas from
> mainstream IDE's.
>Personally I wonder what the goal of Nautilus is?
Dont know either - but according to the SqS page
http://squeaksource.com/Nautilus/
it a new browser based on RPackage and Announcements
with fancy goodies like groups and multi-selections, ...
and it will be based on Ring.
>IMHO fixed lists, a
On 29 August 2011 13:54, Alexandre Bergel wrote:
> Since there is ob, I personally use Nautilus. It provides interesting
> functionalities
> such as grouping packages and the hierarchies view (such as in vw). Importing
> things are missing however, including refactorings.
Personally I wonder wha
>> I do not know. I will continue to use OB.
>
> Lukas, if you get a version working in 1.4, will you let me know/release it?
It took several man-weeks to get everything running in Pharo 1.3 and
there are still quite a few of issues left. Next on my list is to
stabilize everything and to get some
Since there is ob, I personally use Nautilus. It provides interesting
functionalities such as grouping packages and the hierarchies view (such as in
vw). Importing things are missing however, including refactorings.
Alexandre
Le 29 août 2011 à 07:28, "Sean P. DeNigris" a écrit :
>
> Luka
Lukas Renggli wrote:
>
> I do not know. I will continue to use OB.
>
Lukas, if you get a version working in 1.4, will you let me know/release it?
Sean
--
View this message in context:
http://forum.world.st/Omnibrowser-in-1-4-tp3774180p3775979.html
Sent from the Pharo Smalltalk mailing list a
On 29.08.2011, at 18:14, DeNigris Sean wrote:
> What is the purpose of #haltIf: aBlock?
>
> Right now, you can pass any of the following to Object>>haltIf:
> - aBlock taking an optional argument which is automatically set to the
> receiver of #halt
> - aSelector which looks up the call chain a
On Aug 29, 2011, at 1:19 PM, Sean P. DeNigris wrote:
>
> Stéphane Ducasse wrote:
>>
>> and we could keep all the Object method in a extension of the halt
>> packages and just some of them as forward to Halt.
>>
>
> Why don't we just remove all halt methods from Object? What does it buy you
>
On Aug 29, 2011, at 12:56 PM, Lukas Renggli wrote:
> On 29 August 2011 09:29, Stéphane Ducasse wrote:
>> and we could keep all the Object method in a extension of the halt packages
>> and just some of them as forward to Halt.
>>
>> I know that there was an attempt on the inbox to do that. But
Stéphane Ducasse wrote:
>
> and we could keep all the Object method in a extension of the halt
> packages and just some of them as forward to Halt.
>
Why don't we just remove all halt methods from Object? What does it buy you
to say "self halt" instead of "Halt now", but we gain less code and t
What is the purpose of #haltIf: aBlock?
Right now, you can pass any of the following to Object>>haltIf:
- aBlock taking an optional argument which is automatically set to the
receiver of #halt
- aSelector which looks up the call chain and halts if present
- aBoolean
So, whatever the condit
>> There are currently no plans to make OB work in upcoming Pharo
>> versions; Pharo 1.4 is supposed to have its own much better browser
>> framework.
>
> What are the advantages compared to OB?
I do not know. I will continue to use OB.
Lukas
--
Lukas Renggli
www.lukas-renggli.ch
On 29 August 2011 09:29, Stéphane Ducasse wrote:
> and we could keep all the Object method in a extension of the halt packages
> and just some of them as forward to Halt.
>
> I know that there was an attempt on the inbox to do that. But I was worried
> that people will complain.
> Now cleaning O
Hi,I forgot to mention that a CompiledMethod offers a view with the bytecode.Just to give you an idea of what it takes to extend the inspector, here is the implementation needed for adding the bytecode view to a CompiledMethod object:CompiledMethod>>gtInspectorBytecodeIn: composite composite text
self deprecate:in:on: or something like that.
On Aug 29, 2011, at 11:56 AM, Sean P. DeNigris wrote:
>
> marcus.denker wrote:
>>
>> Yes, I would say remove.
>>
>
> I've never removed a core method. What is the latest deprecation policy? Or
> just remove?
>
> Sean
>
> --
> View this message i
Hi,
I am looking for a sort of FlowLayout which works the same way usually text is
handled:
All submorphs are put on a single line and wrapped when the border is hit.
Is there already a layout which does this?
marcus.denker wrote:
>
> Yes, I would say remove.
>
I've never removed a core method. What is the latest deprecation policy? Or
just remove?
Sean
--
View this message in context: http://forum.world.st/Halt-tp3774723p3775839.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com
2011/8/29 Nicolas Cellier
> 2011/8/29 Levente Uzonyi :
> > On Mon, 29 Aug 2011, Stéphane Ducasse wrote:
> >
> >> and we could keep all the Object method in a extension of the halt
> >> packages and just some of them as forward to Halt.
> >>
> >> I know that there was an attempt on the inbox to do
On Aug 29, 2011, at 11:48 AM, Sean P. DeNigris wrote:
>
> Sean P. DeNigris wrote:
>>
>> 3. Is anyone using the versions that take a string message (e.g.
>> #haltOnce:). A halt brings you into a debugger, so is the extra info worth
>> the added complexity? p.s. right now, the versions are cut-an
Sean P. DeNigris wrote:
>
> 3. Is anyone using the versions that take a string message (e.g.
> #haltOnce:). A halt brings you into a debugger, so is the extra info worth
> the added complexity? p.s. right now, the versions are cut-and-pastes of
> each other
>
What about the versions that take a
Anyway, (Halt ifTrue: a = 2) does not make it. We all expect the
ifTrue: condition to lie left of the message...
So Halt if: a = 2, or Halt when: a = 2 are far better selectors IMO.
Nicolas
2011/8/29 Luc Fabresse :
>
> 2011/8/29 Levente Uzonyi
>>
>> On Mon, 29 Aug 2011, Stéphane Ducasse wrote:
>
2011/8/29 Levente Uzonyi :
> On Mon, 29 Aug 2011, Stéphane Ducasse wrote:
>
>> and we could keep all the Object method in a extension of the halt
>> packages and just some of them as forward to Halt.
>>
>> I know that there was an attempt on the inbox to do that. But I was
>> worried that people wi
How?
because I get
Foo new ifTrue: ['sss']
mustBeABoolean
On Aug 29, 2011, at 10:50 AM, Damien Cassou wrote:
> 2011/8/29 Levente Uzonyi :
>> Currently you can't send #ifTrue: to any object.
>
> Looks like it works on Pharo 1.3. I created a class with an #ifTrue:
> method and I can call it wit
> Currently you can't send #ifTrue: to any object.
>
> I did not get this interesting point.
> I know that ifTrue: ... messages are optimized with special bytecodes.
> But, implementing Halt class>>ifTrue: would work.
> What am I missing?
>
> Thanks,
Luc indeed ifTrue: is handled specially by th
>
>> and we could keep all the Object method in a extension of the halt packages
>> and just some of them as forward to Halt.
>>
>> I know that there was an attempt on the inbox to do that. But I was worried
>> that people will complain.
>> Now cleaning Object would be nice.
>>
>> Stef
>>
>>
2011/8/29 Levente Uzonyi :
> Currently you can't send #ifTrue: to any object.
Looks like it works on Pharo 1.3. I created a class with an #ifTrue:
method and I can call it without problem
--
Damien Cassou
http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until J
On 23 Aug 2011, at 23:44, Bernat Romagosa wrote:
> Any ideas?
Many people, including myself, have various images running for many weeks and
even months, so it is possible. I am guessing that you are running some Seaside
(maybe Pier) with one of the standard HTTP servers ? Those should not leav
1 - 100 of 108 matches
Mail list logo
