On Tue, Jun 18, 2013 at 11:23 PM, Tristan Bourgois
wrote:
> I hope you like this little demo :) And I hope I could make some others :)
That's really awesome work Tristan. Nevertheless, the 4th part of the
video is completely black for me. When will Cade be open-sourced :-)?
--
Damien Cassou
htt
On Jun 13, 2013, at 2:48 PM, Marcus Denker wrote:
>
> On Jun 13, 2013, at 2:23 PM, Sean P. DeNigris wrote:
>
>> Why do we get [...] when Opal is not active? Why can't we keep the old
>> behavior?
>>
>
>
> Soon we will switch to Opal, there are just 2 bugs left (that I know of ;-)
> We whe
30207
-
10944 Enable Opal in 3.0
https://pharo.fogbugz.com/f/cases/10944
Just does a
SmalltalkImage compilerClass: OpalCompiler.
OpalCompiler recompileAll.
Yes… we managed to run out of known bugs. So let's find some more… :-)
30206
-
10949 Bug when a method is recategorized
https://pharo.fogbugz.com/f/cases/10949
10963 Nautilus add accessors
https://pharo.fogbugz.com/f/cases/10963
10962 NewList fix in deselectAll
https://pharo.fogbugz.com/f/cases/10962
Diff information:
30205
-
10951 Debugger add new Method class choice dialog should show traits
https://pharo.fogbugz.com/f/cases/10951
10958 Tabs model
https://pharo.fogbugz.com/f/cases/10958
10959 metacelloPlatformAttributes not updated for Pharo3
https://pharo.fogbugz
Hi Gary,
yes, I'm interested by help and pointers about TTF. It's a planned evolution of
Artefact.
About barcodes generation, why don't use Artefact directly ? You can draw
barcodes with the PDFDraw elements (PDFLineElement, PDFRectElement, etc.) and
print the document on stickers.
In the
Very cool! Thanks for sharing!
On 18.06.2013, at 23:23, Tristan Bourgois wrote:
> Hi!
>
> I'm actually working at Thalès on a graphic framework named Cade.
> Cade manage event, animation and have a double bufferization.
> All the graphics rendering of Cade is based on Athens :)
>
> This is
Hi!
I'm actually working at Thalès on a graphic framework named Cade.
Cade manage event, animation and have a double bufferization.
All the graphics rendering of Cade is based on Athens :)
This is a little demo of my work :
http://www.youtube.com/watch?v=gGlEKtNKl7s.
(Watch it in HD to see the c
I prefer the onKeyCombination* because of the following rationale:
- to me a shortcut is the association between a key combination and an
action
- a key combination is a combination of keys :), which is associated with
an action
Stef, so far I changed the asShortcut => asKeyCombination, following
Chris wrote:
>You should be able to create a form, paint it white, draw on it with a barcode
>TTF font, export that form to JPEG, and >then use that JPEG into Artefact.
That won't work. Barcode readers need clean black-white transitions and that is
something
JPEG compression cannot provide (unle
On 18 June 2013 19:16, Martin Dias wrote:
> awesome, thank you!
>
> On Tue, Jun 18, 2013 at 3:48 PM, Sebastian Tleye wrote:
>> Done :)
>> You can download the fix and not suffer anymore :P
Dang it, now I'm going to have to copy this excellent idea!
frank
>> 2013/6/18 Camillo Bruni
>>>
>>> yes
+1
> awesome, thank you!
Hi sean
I like your browser showing issue.
What does it show?
Because I'm always lost with figbuz :)
For the DateAndTime long time ago camillo was mentioning that dart as a
nice way to specify how to print dates so may be we should have a look
Stef
On Jun 18, 20
awesome, thank you!
On Tue, Jun 18, 2013 at 3:48 PM, Sebastian Tleye wrote:
> Done :)
> You can download the fix and not suffer anymore :P
>
>
> 2013/6/18 Camillo Bruni
>>
>> yes please :)
>>
>> https://pharo.fogbugz.com/default.asp?10951
>>
>> On 2013-06-18, at 14:59, Camille Teruel wrote:
>>
On Jun 18, 2013, at 7:21 PM, GOUBIER Thierry wrote:
> The problem with onkeypress, onkeydown, onkeyup is that they are low-level
> events compared to the shortcuts we are talking about.
>
> A shortcut is at least one key, but is usually a key + a modifier or a
> sequence of key + modifiers (s
Hello Gary
I'm sure that Olivier is interested.
Stef
On Jun 18, 2013, at 6:37 PM, "Gary Chambers" wrote:
> Well, hoping to work with Torsten on barcodes in general, given we have
> support for canvas based drawing of a few formats here at Pinesoft.
>
> Also, if Olivier would like some help
The problem with onkeypress, onkeydown, onkeyup is that they are low-level
events compared to the shortcuts we are talking about.
A shortcut is at least one key, but is usually a key + a modifier or a sequence
of key + modifiers (such as the emacs ^X ^C ($x ctrl, $c ctrl). The Keymapping
stuff
On 18 juin 2013, at 17:04, Clément Bera wrote:
> I don't like this new structure. Then people coming from non object language
> using all the time control structure will do :
>
> #someRandomObject if: then: else: thinking of doing a C style condition and
> not using at all the receiver.
Come
Well, hoping to work with Torsten on barcodes in general, given we have support
for canvas based drawing of a few formats here at Pinesoft.
Also, if Olivier would like some help with TTF in PDFs I can give some pointers
etc.
Regards, Gary
- Original Message -
From: Chris Cunningha
On 18 Jun 2013, at 17:24, "Esteban A. Maringolo" wrote:
> I did some tests with AWS EC2, and it is good to know to know Pharo is so
> simple to install in this provider.
>
> It looks more like a VPS provider, or am I missing something? Because I
> haven't seen an autoscaling (up or out) optio
You should be able to create a form, paint it white, draw on it with a
barcode TTF font, export that form to JPEG, and then use that JPEG into
Artefact.
Not really straight-forward, but it should work.
*Note: I've found that writing JPEG's in Pharo, it assumes that the
background is BLACK if it i
2013/6/18 Clément Bera
> On Javascript, there are :
>
> onkeypress
> onkeydown
> onkeyup
>
>
> I think we should have same API than other languages, especially popular
> ones. So 1 of these 3 would be the best for me.
>
> Why not onKeyPress:do: ?
+1 to each of the last two statements.
On Javascript, there are :
- onkeypress
- onkeydown
- onkeyup
I think we should have same API than other languages, especially popular
ones. So 1 of these 3 would be the best for me.
Why not onKeyPress:do: ?
2013/6/18 Goubier Thierry
> Additionally, this is processing on a shortcut
Sven Van Caekenberghe-2 wrote
>> * ZnNetworkingUtils>>isPortAvailable: (doesn't take ip6 into account)
>
> I am interested in this one but I can't open the package named:
> 'ZnNetworkingUtils>>usedPorts', can you ?
No, I can't either... but it's okay because I moved the method into
Zinc-HTTPSpd ;
Marcus Denker-4 wrote
> Keep in mind that we can integrate important fixes in 2.0…. someone just
> needs to take initiative.
Thanks for the reminder! I'm clear about that after all the work we did
together getting 2.0 issues backported to 1.4 :) And... my understanding is
that we have a policy to
Le 18/06/2013 15:35, Stéphane Ducasse a écrit :
ok I will try to find my way but yes it would be good to offer an
infrastructure to avoid that everybody reinvent the wheel
At the same time, beware of over-architecturing. I hates a framework
where hacking it to do a simple subset of the "do e
I don't like this new structure. Then people coming from non object
language using all the time control structure will do :
#someRandomObject if: then: else: thinking of doing a C style condition and
not using at all the receiver.
I like how it is now.
2013/6/18 kilon
> Very few things are tr
Additionally, this is processing on a shortcut, that is possibly on a
sequence of keys...
So, onKey:do: isn't very good.
The replacement of asShortcut by asKeyCombination in 3.0 wasn't too
good, either.
But, to be coherent, it should certainly be:
onKeyCombination:do:
Thierry
Le 18/06/20
On 18 June 2013 16:31, Sven Van Caekenberghe wrote:
>
> On 18 Jun 2013, at 14:43, Benjamin
> wrote:
>
>> You may not be the only one, but you probably are the only whose job is to
>> address Pharo issues :)
>
> And we all get this warm cozy feeling when Igor fixes important low level
> stuff ;
On 18 June 2013 15:59, Stéphane Ducasse wrote:
> Hi guillermo
>
> I thought that we decided to change and not use
> on: do: for shortCuts (I'm happy that we change because for me it
> took me a while to understand that the key was not an exception.
>
> Could we deprecate on:do: on KMDispa
Sean,
On 18 Jun 2013, at 15:30, DeNigris Sean wrote:
> * ZnNetworkingUtils>>isPortAvailable: (doesn't take ip6 into account)
I am interested in this one but I can't open the package named:
'ZnNetworkingUtils>>usedPorts', can you ?
Sven
On 18 Jun 2013, at 14:43, Benjamin wrote:
> You may not be the only one, but you probably are the only whose job is to
> address Pharo issues :)
And we all get this warm cozy feeling when Igor fixes important low level stuff
;-)
> Ben
>
> On Jun 18, 2013, at 11:17 AM, Igor Stasenko wrote:
Very few things are truly necessary in life, programming languages are not
amongst them.
As I said , for me how already things work in pharo is fine concerning
ifTrue: and friends .
--
View this message in context:
http://forum.world.st/Pharo-dev-Object-if-then-else-tp4693871p4693952.html
Se
On Jun 18, 2013, at 3:31 PM, DeNigris Sean wrote:
> Are you both impatient and conservative (and apparently confused) like me? I
> want to use the stable release of Pharo with the best new features of the
> alpha version. Also, do you ever think of cool enhancements to the IDE that
> for what
I still believe all of that is unnecessary sugar, that ends been more annoying
than helpful.
no matter the name we choose :)
On Jun 18, 2013, at 3:53 PM, kilon wrote:
> ifEvaluatesToTrueUsing sounds like an overkill to me and unnecessary , its
> common convention in all popular languages than
On 18 June 2013 14:43, Benjamin wrote:
> You may not be the only one, but you probably are the only whose job is to
> address Pharo issues :)
>
Toucher! :)
Yes, i should look again at Delays.
> Ben
>
> On Jun 18, 2013, at 11:17 AM, Igor Stasenko wrote:
>
> On 18 June 2013 11:11, Stéphane Ducas
Hi guillermo
I thought that we decided to change and not use
on: do: for shortCuts (I'm happy that we change because for me it took
me a while to understand that the key was not an exception.
Could we deprecate on:do: on KMDispatcher?
What is the replacement?
onKey: do:
initi
ifEvaluatesToTrueUsing sounds like an overkill to me and unnecessary , its
common convention in all popular languages than an if always needs to
evaluate to true to execute and if it evaluates to false then "else" handles
it.
--
View this message in context:
http://forum.world.st/Pharo-dev-Ob
Le 18/06/2013 15:34, Stéphane Ducasse a écrit :
is
buildShortcut:
*
*
*standard?*
No. Lack of infrastructure for that :) Spec has some of the relevant
bits and could automatize this a bit.
KMDispatcher still doesn't work totally as I would like.
*is it invoked automatically?*
Yes. GUI
Done :)
You can download the fix and not suffer anymore :P
2013/6/18 Camillo Bruni
> yes please :)
>
> https://pharo.fogbugz.com/default.asp?10951
>
> On 2013-06-18, at 14:59, Camille Teruel wrote:
> > On 18 juin 2013, at 14:56, Martin Dias wrote:
> >
> >> Hi
> >>
> >> I informally reported th
ok I will try to find my way but yes it would be good to offer an
infrastructure to avoid that everybody reinvent the wheel
Stef
On Jun 18, 2013, at 2:49 PM, Benjamin
wrote:
> For menus, there is nothing spec related here (yet).
> If you use pragmas, for defining your menus/shortcuts, there is
is
buildShortcut:
standard?
is it invoked automatically?
Stef
On Jun 18, 2013, at 1:48 PM, Goubier Thierry wrote:
> Hi Stéphane,
>
> look into the AltBrowser code. You'll find commands that are both shortcuts
> and menu items (subclasses of AltCommand).
>
> https://github.com/ThierryGoubi
yes please :)
https://pharo.fogbugz.com/default.asp?10951
On 2013-06-18, at 14:59, Camille Teruel wrote:
> On 18 juin 2013, at 14:56, Martin Dias wrote:
>
>> Hi
>>
>> I informally reported this "feature requirement" today to Sebastian,
>> but I wanted to post it to all.
>>
>> When the debugge
On 18 juin 2013, at 14:56, Martin Dias wrote:
> Hi
>
> I informally reported this "feature requirement" today to Sebastian,
> but I wanted to post it to all.
>
> When the debugger is shown after a MNU, the developer can press the
> button "Create method". A list of the superclasses is shown to
Hi
I informally reported this "feature requirement" today to Sebastian,
but I wanted to post it to all.
When the debugger is shown after a MNU, the developer can press the
button "Create method". A list of the superclasses is shown to the
developer, so he/she can choose in which class crate the m
It feels to me as if this code wants to be on the temp. So perhaps,
> | temp |
> temp := .
> temp
> ifTrue: [ temp ]
> ifFalse: [ temp ].
can become
doSomething
and on Temp:
doSomething
self
ifTrue: [ self ]
ifFalse: [ self ]
It often works out nicer if you move th
For menus, there is nothing spec related here (yet).
If you use pragmas, for defining your menus/shortcuts, there is (or was) a
specific registration class supporting made for defining both in one.
It was never adopted, so I do not know where to find it again, sorry
Ben
On Jun 18, 2013, at 1:48
You may not be the only one, but you probably are the only whose job is to
address Pharo issues :)
Ben
On Jun 18, 2013, at 11:17 AM, Igor Stasenko wrote:
> On 18 June 2013 11:11, Stéphane Ducasse wrote:
>> Once igor finishes the TxModel and Athens it was planned to address the
>> Delay probl
On Jun 18, 2013, at 1:52 PM, Igor Stasenko wrote:
> On 18 June 2013 13:26, Guillermo Polito wrote:
>>
>>
>>
>> On Tue, Jun 18, 2013 at 1:01 PM, Esteban Lorenzano
>> wrote:
>>>
>>> well... afaik, no one outside pharo community is using the configurations,
>>> the other guys on vm-dev prefer
On 18 June 2013 13:26, Guillermo Polito wrote:
>
>
>
> On Tue, Jun 18, 2013 at 1:01 PM, Esteban Lorenzano
> wrote:
>>
>> well... afaik, no one outside pharo community is using the configurations,
>> the other guys on vm-dev prefer the old way of doing things.
>>
>> also, the group "pharo" is inte
On 2013-06-18, at 13:26, Guillermo Polito wrote:
> On Tue, Jun 18, 2013 at 1:01 PM, Esteban Lorenzano wrote:
>
>> well... afaik, no one outside pharo community is using the configurations,
>> the other guys on vm-dev prefer the old way of doing things.
>>
>> also, the group "pharo" is intended
Le 18/06/2013 13:41, Frank Shearar a écrit :
On 18 June 2013 12:35, Goubier Thierry wrote:
Le 18/06/2013 13:09, Esteban Lorenzano a écrit :
I do not like it :)
also, you already have #in:
which is more generic and allows simplifications:
in: [ :blah |
blah = myTest
Hi Stéphane,
look into the AltBrowser code. You'll find commands that are both
shortcuts and menu items (subclasses of AltCommand).
https://github.com/ThierryGoubier/AltBrowser/blob/master/Alt-Browser.package/AltCommand.class/instance/addItemToMenu..st
https://github.com/ThierryGoubier/AltBro
On 18 June 2013 12:35, Goubier Thierry wrote:
>
>
> Le 18/06/2013 13:09, Esteban Lorenzano a écrit :
>
>> I do not like it :)
>>
>> also, you already have #in:
>> which is more generic and allows simplifications:
>>
>> in: [ :blah |
>> blah = myTest
>> ifTrue: [ blah some
IMO the most important consideration should be readability: one should be
able to guess what the method does without having to look how it is
implemented, which means that the naming is crucial.
To me *personally* it is not intuitive what is meant by *anObject if:
aBlockOrSelector do: aBlock elseD
What I think. Well the point of Smalltalk is that it offers you a language
that allows you to play with the syntax. Thats pretty much the heart of
Smalltalk. So I would definitely not be against offering an alternative to
if conditions.
Personally I have no problem with the original syntax. I woul
Hi ben
I want to define some menu for my logging Tool UI. And I was wondering how
- define menu
- avoid duplication with shortcut
I looked at the EyeInspector but it is not clear to me. Do you have a
better example I could read?
Stef
I never heard of that, it is cool, Esteban !
There are not many senders though.
Thx,
Sven
On 18 Jun 2013, at 13:09, Esteban Lorenzano wrote:
> I do not like it :)
>
> also, you already have #in:
> which is more generic and allows simplifications:
>
> in: [ :blah |
> blah = myTest
>
Le 18/06/2013 13:09, Esteban Lorenzano a écrit :
I do not like it :)
also, you already have #in:
which is more generic and allows simplifications:
in: [ :blah |
blah = myTest
ifTrue: [ blah some ] ]
ifFalse: [ blah other ] ]
This is cool :) Didn't
On Tue, Jun 18, 2013 at 1:01 PM, Esteban Lorenzano wrote:
> well... afaik, no one outside pharo community is using the configurations,
> the other guys on vm-dev prefer the old way of doing things.
>
> also, the group "pharo" is intended to include the things necessary to
> produce a "pharo vm"...
On 18 juin 2013, at 13:09, Esteban Lorenzano wrote:
> I do not like it :)
I understand that (especially from a conservative who doesn't even like colors
;D ).
>
> also, you already have #in:
> which is more generic and allows simplifications:
>
> in: [ :blah |
> blah = myTest
>
On Jun 18, 2013, at 11:17 AM, Igor Stasenko wrote:
> On 18 June 2013 11:11, Stéphane Ducasse wrote:
>> Once igor finishes the TxModel and Athens it was planned to address the
>> Delay problem.
>>
>
> I don't think i am the only one who capable to fix it. :)
I would love to be able to do it
I do not like it :)
also, you already have #in:
which is more generic and allows simplifications:
in: [ :blah |
blah = myTest
ifTrue: [ blah some ] ]
ifFalse: [ blah other ] ]
and also the advantage is that you are not restricted to #ifTrue:ifFalse:
well... afaik, no one outside pharo community is using the configurations, the
other guys on vm-dev prefer the old way of doing things.
also, the group "pharo" is intended to include the things necessary to produce
a "pharo vm"... this is what time ago was in the ConfigurationOfPharoVM. That
m
Le 18/06/2013 12:27, Camille Teruel a écrit :
On 18 juin 2013, at 11:20, Goubier Thierry wrote:
Hi Camille,
It's not bad as things goes, because it does look a bit like
non-smalltalk code (i.e. the if then else structure) except that the
precise meaning is very much Smalltalk :
Ok the nam
On 18 juin 2013, at 11:20, Goubier Thierry wrote:
> Hi Camille,
>
> It's not bad as things goes, because it does look a bit like non-smalltalk
> code (i.e. the if then else structure) except that the precise meaning is
> very much Smalltalk :
Ok the name may be confusing.
So if you rename it
On 18 juin 2013, at 11:10, Stéphane Ducasse wrote:
> is it not slower?
Yes a bit slower.
> and I would remove as much as method as possible from Object.
>
> why
>> | temp |
>> temp := .
>> temp
>> ifTrue: [ temp ]
>> ifFalse: [ temp ].
>
> is not good enough?
If it is the whole
On 18 June 2013 11:20, Goubier Thierry wrote:
> Hi Camille,
>
> It's not bad as things goes, because it does look a bit like non-smalltalk
> code (i.e. the if then else structure) except that the precise meaning is
> very much Smalltalk :
>
> if: has a receiver, and there is a not so intuitive rel
On 18 June 2013 11:11, Stéphane Ducasse wrote:
> Once igor finishes the TxModel and Athens it was planned to address the Delay
> problem.
>
I don't think i am the only one who capable to fix it. :)
Something broken in restoring Delay(s) after image restart (they
hanging for too far in the futur
Hi Camille,
It's not bad as things goes, because it does look a bit like
non-smalltalk code (i.e. the if then else structure) except that the
precise meaning is very much Smalltalk :
if: has a receiver, and there is a not so intuitive relationship between
the bloc parameters and the receiver
On Jun 17, 2013, at 2:08 PM, Sean P. DeNigris wrote:
> Stéphane Ducasse wrote
>> Are you interested to get your name with the one of Ze fabulous crazy
>> french researcher?
>> What a fame, isnt?
>
> Ha ha, I can see the paparazzi lining up now ;) I'd be happy to help. I'm
> exploring and exper
Once igor finishes the TxModel and Athens it was planned to address the Delay
problem.
Stef
is it not slower?
and I would remove as much as method as possible from Object.
why
> | temp |
> temp := .
> temp
> ifTrue: [ temp ]
> ifFalse: [ temp ].
is not good enough?
And finally we should kill as much as possible of these if…. so
> Hello everyone.
>
> I see a lot of code
I would simplify :)
Stef
On Jun 18, 2013, at 10:26 AM, Guillermo Polito
wrote:
> Hi guys!
>
> I worked yesterday on making VMMaker load and work in Pharo2.0 with
> filesystem. Now, I want to push my changes in a new development version of
> ConfigurationOfCog. But I have some questions:
>
On 18 Jun 2013, at 10:38, Camillo Bruni wrote:
> the original issue you posted was closed because it is a duplicate of this one
> https://pharo.fogbugz.com/default.asp?7526
I saw that, but the title is too restrictive I think.
> where you will fine a proper script to kill hanging process
Hello everyone.
I see a lot of code that follows the following pattern:
ifTrue: [ ]
ifFalse: [ ].
The classic refactoring is to store in a temp to avoid
repetition:
| temp |
temp := .
temp
ifTrue: [ temp ]
ifFalse: [ temp ].
Then is evaluated once and the name of t
Hi Sven,
This is not merged on purpose, as Camillo's patch needs some review and
thinking :)
Nico
On Jun 17, 2013, at 3:29 PM, Sven Van Caekenberghe wrote:
> BTW: there is even code in StHub, namely Hub-CamilloBruni.119, that was not
> merged properly AFAICT.
--
Nicolas Petton
http://www.ni
On 18 juin 2013, at 10:05, Sven Van Caekenberghe wrote:
>
> On 18 Jun 2013, at 09:47, Camille Teruel wrote:
>
>>
>> On 18 juin 2013, at 09:32, Sven Van Caekenberghe wrote:
>>
>>> Hi,
>>>
>>> It seems that
>>> https://pharo.fogbugz.com/f/cases/10760/Lots-and-Lots-of-Delay-wait-processes-die
Hi Torsten,
Artefact don't support TTF fonts for the moment but it's planned in futures
versions.
Best regards
Olivier :-)
Le 14 juin 2013 à 16:16, Milan Mimica a écrit :
> You just need a TTF font. Does Artefact support TTF? hpdf does.
>
>
> On 14 June 2013 13:58, Torsten Bergmann wrote:
>
On 17 June 2013 21:24, Alexandre Bergel wrote:
> Hi Igor,
>
> I currently have two students who are very motivated in working with the open
> gl binding.
> However we are experiencing stability problems. Last week I created a moose
> image with NBOpenGL and SourceCity and it worked well "SourceC
On 18 June 2013 10:26, Guillermo Polito wrote:
> Hi guys!
>
> I worked yesterday on making VMMaker load and work in Pharo2.0 with
> filesystem. Now, I want to push my changes in a new development version of
> ConfigurationOfCog. But I have some questions:
>
> Is ConfigurationOfCog used by other pe
the original issue you posted was closed because it is a duplicate of this one
https://pharo.fogbugz.com/default.asp?7526
where you will fine a proper script to kill hanging processes...
On 2013-06-18, at 10:05, Sven Van Caekenberghe wrote:
> On 18 Jun 2013, at 09:47, Camille Teruel wr
Hi guys!
I worked yesterday on making VMMaker load and work in Pharo2.0 with
filesystem. Now, I want to push my changes in a new development version of
ConfigurationOfCog. But I have some questions:
Is ConfigurationOfCog used by other people besides Pharo?
Because so far I see:
- there are two
On 18 Jun 2013, at 09:47, Camille Teruel wrote:
>
> On 18 juin 2013, at 09:32, Sven Van Caekenberghe wrote:
>
>> Hi,
>>
>> It seems that
>> https://pharo.fogbugz.com/f/cases/10760/Lots-and-Lots-of-Delay-wait-processes-die-to-Cookie-contents
>> is closed, but the problem remains.
>>
>> Yest
20607
-
10938 backport 2.0 : an MCOrganizationDefinition should only remove empty
categories during unload
https://pharo.fogbugz.com/f/cases/10938
10909 Backport Pharo2.0: Prepare isHeadless for new VMs with double dash --
arguments
https://pharo.fogbugz.com/f/cases/
On 18 juin 2013, at 09:32, Sven Van Caekenberghe wrote:
> Hi,
>
> It seems that
> https://pharo.fogbugz.com/f/cases/10760/Lots-and-Lots-of-Delay-wait-processes-die-to-Cookie-contents
> is closed, but the problem remains.
>
> Yesterday I test deployed a brand new 3.0 image. It has more than 80
86 matches
Mail list logo
