Re: [Pharo-dev] [squeak-dev] Time now print24

[Brad Selfridge]

+100 for ISO. 



-
Brad Selfridge
--
View this message in context: 
http://forum.world.st/Time-now-print24-tp4905425p4905677.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Sound on Debian

[J.F. Rick]

Th vm-sound-pulse plugin packaged with the Squeak VM works on Ubuntu.

Cheers,

Jeff

On Fri, Jul 8, 2016 at 1:14 PM Dimitris Chloupis 
wrote:

> Was not able to make it work in Ubuntu either, for me it work only on MacOS
>
> On Fri, Jul 8, 2016 at 5:54 PM jannik laval 
> wrote:
>
>> Hi pharoers,
>>
>> I just tried sounds on phratch on Debian 8. It returns this message:
>>
>> sound_Start(default)
>> soundStart: snd_add_pcm_handler: Fonction non implantée
>>
>> Is it a problem known ?
>>
>> Here is my configuration:
>>
>> Image
>> -
>> /usr/lib/Phratch/shared/Pharo4.0.image
>> Pharo4.0
>> Latest update: #40626
>> Unnamed
>>
>> Virtual Machine
>> ---
>> /usr/lib/Phratch/bin/pharo
>> NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid:
>> acc98e51-2fba-4841-a965-2975997bba66 May 15 2014
>> NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid:
>> acc98e51-2fba-4841-a965-2975997bba66 May 15 2014
>> https://github.com/pharo-project/pharo-vm.git Commit:
>> ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 +0200
>> By: Esteban Lorenzano  Jenkins build #14826
>>
>> Unix built on May 15 2014 18:29:39 Compiler: 4.6.3
>> VMMaker versionString https://github.com/pharo-project/pharo-vm.git
>> Commit: ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04
>> +0200 By: Esteban Lorenzano  Jenkins build #14826
>> NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid:
>> acc98e51-2fba-4841-a965-2975997bba66 May 15 2014
>> NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid:
>> acc98e51-2fba-4841-a965-2975997bba66 May 15 2014
>>
>>
>> Cheers,
>> --
>> ~~Jannik Laval~~
>> Enseignant-chercheur
>> Responsable Pédagogique Licence Coordonnateur de Projet en Système
>> d'Information
>> IUT Lumière, Université Lyon Lumière
>> laboratoire DISP
>> http://www.jannik-laval.eu
>> http://www.phratch.com
>> http://www.approchealpes.info
>>
>

Re: [Pharo-dev] [squeak-dev] Time now print24

[Alistair Grant]

On Fri, Jul 08, 2016 at 10:49:51AM +0200, Tobias Pape wrote:
> 
> On 07.07.2016, at 18:33, Eliot Miranda  wrote:
> 
> > Hi All,
> > 
> > how does one produce a nice timestamp, simply date and time as in
> > 
> > 7/7/2016 09:19:38
> 
> ...
> 
> PS: I'd prefer ISO, nonetheless: https://xkcd.com/1179/

+2 (1 for ISO and 1 for the xkcd reference)

Cheers,
Alistair

Re: [Pharo-dev] [Holidays] 14 days no updates: 14th to end of July

[Peter Uhnák]

On Fri, Jul 8, 2016 at 9:10 PM, Sven Van Caekenberghe  wrote:

>
> > On 08 Jul 2016, at 21:04, Yuriy Tymchuk  wrote:
> >
> > Have fun dear integrators! :)
>
> +10
>

+∫

Re: [Pharo-dev] [Holidays] 14 days no updates: 14th to end of July

[Sven Van Caekenberghe]

> On 08 Jul 2016, at 21:04, Yuriy Tymchuk  wrote:
> 
> Have fun dear integrators! :)

+10

>> On 08 Jul 2016, at 19:57, stepharo  wrote:
>> 
>> Hi marcus
>> 
>> I will see if the temperature forces me to stay inside after afternoon naps 
>> and before jumping in water.
>> In such case I will looks at easy fixes.
>> But I will not do it regularly. I will probably have a look the week of 20 
>> and take a real break from tomorrow to end of next week.
>> 
>> Stef
>>> Hi,
>>> 
>>> We just saw that everyone who can press the button for a final integration
>>> will be on Holidays from July 14 to the end of the month.
>>> 
>>> This means there will be no update, but the issue tracker will stay open of 
>>> course,
>>> so issues can be submitted, fixed and reviewed… they will just not end up 
>>> the downloadable
>>> image for that 2 weeks.
>>> 
>>> Marcus
>>> 
>> 
>> 
> 
> 

Re: [Pharo-dev] [Holidays] 14 days no updates: 14th to end of July

[Yuriy Tymchuk]

Have fun dear integrators! :)

> On 08 Jul 2016, at 19:57, stepharo  wrote:
> 
> Hi marcus
> 
> I will see if the temperature forces me to stay inside after afternoon naps 
> and before jumping in water.
> In such case I will looks at easy fixes.
> But I will not do it regularly. I will probably have a look the week of 20 
> and take a real break from tomorrow to end of next week.
> 
> Stef
>> Hi,
>> 
>> We just saw that everyone who can press the button for a final integration
>> will be on Holidays from July 14 to the end of the month.
>> 
>> This means there will be no update, but the issue tracker will stay open of 
>> course,
>> so issues can be submitted, fixed and reviewed… they will just not end up 
>> the downloadable
>> image for that 2 weeks.
>> 
>>  Marcus
>> 
> 
> 

Re: [Pharo-dev] [Holidays] 14 days no updates: 14th to end of July

[stepharo]

Hi marcus

I will see if the temperature forces me to stay inside after afternoon 
naps and before jumping in water.

In such case I will looks at easy fixes.
But I will not do it regularly. I will probably have a look the week of 
20 and take a real break from tomorrow to end of next week.


Stef

Hi,

We just saw that everyone who can press the button for a final integration
will be on Holidays from July 14 to the end of the month.

This means there will be no update, but the issue tracker will stay open of 
course,
so issues can be submitted, fixed and reviewed… they will just not end up the 
downloadable
image for that 2 weeks.

Marcus

Re: [Pharo-dev] Sound on Debian

[Dimitris Chloupis]

Was not able to make it work in Ubuntu either, for me it work only on MacOS

On Fri, Jul 8, 2016 at 5:54 PM jannik laval  wrote:

> Hi pharoers,
>
> I just tried sounds on phratch on Debian 8. It returns this message:
>
> sound_Start(default)
> soundStart: snd_add_pcm_handler: Fonction non implantée
>
> Is it a problem known ?
>
> Here is my configuration:
>
> Image
> -
> /usr/lib/Phratch/shared/Pharo4.0.image
> Pharo4.0
> Latest update: #40626
> Unnamed
>
> Virtual Machine
> ---
> /usr/lib/Phratch/bin/pharo
> NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid:
> acc98e51-2fba-4841-a965-2975997bba66 May 15 2014
> NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid:
> acc98e51-2fba-4841-a965-2975997bba66 May 15 2014
> https://github.com/pharo-project/pharo-vm.git Commit:
> ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 +0200
> By: Esteban Lorenzano  Jenkins build #14826
>
> Unix built on May 15 2014 18:29:39 Compiler: 4.6.3
> VMMaker versionString https://github.com/pharo-project/pharo-vm.git
> Commit: ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04
> +0200 By: Esteban Lorenzano  Jenkins build #14826
> NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid:
> acc98e51-2fba-4841-a965-2975997bba66 May 15 2014
> NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid:
> acc98e51-2fba-4841-a965-2975997bba66 May 15 2014
>
>
> Cheers,
> --
> ~~Jannik Laval~~
> Enseignant-chercheur
> Responsable Pédagogique Licence Coordonnateur de Projet en Système
> d'Information
> IUT Lumière, Université Lyon Lumière
> laboratoire DISP
> http://www.jannik-laval.eu
> http://www.phratch.com
> http://www.approchealpes.info
>

Re: [Pharo-dev] Having comments for pragma?

[Richard Sargent]

Tudor Girba-2 wrote
> Hi,
> 
>> On Jun 27, 2016, at 7:55 PM, Eliot Miranda 

> eliot.miranda@

>  wrote:
>> 
>> Hi Doru,
>> 
>> On Mon, Jun 27, 2016 at 6:36 AM, Tudor Girba 

> tudor@

>  wrote:
>> Hi Eliot,
>> 
>> I agree with most things you say (except the conclusion :)), and I think
>> that we are talking about complementary issues.
>> 
>> As I mentioned before, there already is a need to distinguish between a
>> plain selector and one that is associated with pragmas. This is what you
>> find in PragmaType in Spotter and Inspector. This is a kind of
>> meta-object and having it adds value. I can search for pragmas “type” (we
>> can also call it a PragmaSelector), and I can distinguish between all
>> occurrences of a pragma “type” and its utilization in computation. But,
>> the current implementation of PragmaType is a mere pseudo-meta-object,
>> given that it has no casual connection to the runtime.
>> 
>> What we know from Smalltalk is that the analysis model does not have to
>> differ from the runtime one. The consequence is that every time we do see
>> a difference, we should investigate because we might uncover a hidden
>> need opportunity.
>> 
>> I know the VW model, and indeed, we could have something like:
>> 
>> MyConcept class>>myPragmaDefinition
>> “a comment about the pragma"
>> 
> 
>> 
>> However, this only deals with the definition of the pragma type not with
>> the internal representation. There could still well be an object that
>> encapsulates both the selector and the comment. And that object would
>> also allow us to build tools around it. We could call it a PragmaType,
>> PragmaDefinition, or even PragmaSelector. And we could get the Pragma to
>> point to this type either through an inst var or through a query (I would
>> probably prefer an instvar).
>> 
>> Well, there already /is/ a meta-object called Pragma, and it gets
>> instantiated when one accesses the compiled method via pragmas:
>> 
>> (CompiledMethod allInstances detect: [:m| m pragmas size > 1]) pragmas
>> collect: [:ea| {ea. ea class}] {{
> 
>  . Pragma} . {
> 
>  . Pragma}}
> 
> Yes I know :). An instance of Pragma denotes an concrete annotation of a
> method. I now would like a meta-object that describes all Pragma instances
> having the same selector. For example, the protocol on the class side of
> the Pragma class is actually a query protocol that is better suited for
> the instance side of a PragmaDescription meta-object. For example:
> 
>   Pragma class>>allNamed: aSymbol in: aClass
> 
> would become
> 
>   PragmaDescription>>pragmasIn: aClass
> 
> and you would use it like:
> 
>   (PragmaDescription named: aSymbol) pragmasIn: aClass

I am concerned with this proposal. Effectively, it says only one
person/package can ever define a pragma selector. It would interfere with
two completely independent developers from using  for their
own work.

I think it would be better to expand on  to be able to declare
the symbol, the Pragma class, the comment, etc. which would create the meta
instance you desire, but without closing off independent work.

The the expression /PragmaDescription for: #foo/ would answer a collection
of PragmaDescriptions (0 or more). Other methods in the API could be used to
answer the one and only or throw an error if not exactly one, and so on.

[I know of no way that the individual description could find /just/ its
corresponding  uses. Conversely, I know of no way that the compiler
could reliably determine that a method with  was referring to the
pragma from one declaration versus another. But, I think that is less a
problem than forcing a "Highlander" implementation.]

> Creating an instance of PragmaDescription would imply searching the image
> for the 
> 
>  definition. I would also like to have a Flyweight pool per environment
> such that we always get only one instance of a PragmaDefinition per
> selector (like it happens with Symbols).
> 
> 
>> So we could add the information you want to Pragma, and have it be lazy.
> 
> It does not quite belong to the Pragma. A comment is common to all Pragma
> instances, and having it duplicated at the instance level is less elegant.
> 
> But, looking for the users (all senders of the pragma selector - the
> methods that use the annotation) of a Pragma would be even less
> inconvenient to have on the instance side of Pragma.
> 
> 
>> The Pragma could go search for the defining class-side pragma methods and
>> use the parser to extract the comment(s) when asked.  Hence simple access
>> to pragmas, interested only in the selectors for applying, wouldn't have
>> their performance be impacted.
> 
> The design sketched above would require no runtime penalty for a Pragma
> instance. All code that works now would work identically afterwards. We
> would only have one selector in Pragma to get the corresponding
> description:
> 
> Pragma>>description
>   ^ PragmaDescription named: self selector
> 
> Alternatively, we could modify the 

[Pharo-dev] Sound on Debian

[jannik laval]

Hi pharoers,

I just tried sounds on phratch on Debian 8. It returns this message:

sound_Start(default)
soundStart: snd_add_pcm_handler: Fonction non implantée

Is it a problem known ?

Here is my configuration:

Image
-
/usr/lib/Phratch/shared/Pharo4.0.image
Pharo4.0
Latest update: #40626
Unnamed

Virtual Machine
---
/usr/lib/Phratch/bin/pharo
NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid:
acc98e51-2fba-4841-a965-2975997bba66 May 15 2014
NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid:
acc98e51-2fba-4841-a965-2975997bba66 May 15 2014
https://github.com/pharo-project/pharo-vm.git Commit:
ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 +0200
By: Esteban Lorenzano  Jenkins build #14826

Unix built on May 15 2014 18:29:39 Compiler: 4.6.3
VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit:
ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 +0200
By: Esteban Lorenzano  Jenkins build #14826
NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid:
acc98e51-2fba-4841-a965-2975997bba66 May 15 2014
NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid:
acc98e51-2fba-4841-a965-2975997bba66 May 15 2014


Cheers,
-- 
~~Jannik Laval~~
Enseignant-chercheur
Responsable Pédagogique Licence Coordonnateur de Projet en Système
d'Information
IUT Lumière, Université Lyon Lumière
laboratoire DISP
http://www.jannik-laval.eu
http://www.phratch.com
http://www.approchealpes.info

Re: [Pharo-dev] AthensCairoSurface not getting garbage collected

[J.F. Rick]

I don't have enough evidence either way, but the signs point to no since
the applications that crash are not ones that use form-based paints. I
assume they wouldn't be affected by the flush. We did have one crash on a
form-based one where it crashed after running for 10 hours. My guess is
that one ran out of memory. That crash is probably resolved. But, I'll keep
everybody informed as I work more on it.

Cheers,

Jeff


On Thu, Jul 7, 2016 at 3:28 AM Alexandre Bergel 
wrote:

> Jeff, does this flush reduces the amount of crash you are experiencing?
>
> Alexandre
>
> > On Jul 6, 2016, at 9:01 PM, J.F. Rick  wrote:
> >
> > Nicolai,
> >
> > THANKS! That worked. I no longer have any AthensCairoCanvas hanging
> around after executing "CairoBackendCache flush".
> >
> > Cheers,
> >
> > Jeff
> >
> > On Sun, Jul 3, 2016 at 11:58 AM Nicolai Hess 
> wrote:
> > Hi Jeff,
> >
> > if you use forms to paint on an AthensCairoCanvas, they are cached in
> the CairoBackendCache,
> > can you try to flush that cache whith
> > CairoBackendCache flush.
> >
> >
> > 2016-06-18 18:36 GMT+02:00 J.F. Rick :
> > I'm using Athens rendering for my multi-touch applications on Pharo5. As
> part of that, I create a surface:
> > surface := AthensCairoSurface extent: bounds extent asIntegerPoint.
> >
> > Though the object creating that surface is deleted, the surface sticks
> around. So, each time I run the app, I get another instance of
> AthensCairoSurface hanging around. That means all the forms stick around as
> well. So my image can quickly grow towards the 1GB size.
> >
> >  Is there anything I can do about that? Can I manually get the surface
> to delete itself?
> >
> > Cheers,
> >
> > Jeff
> >
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

[Pharo-dev] [Holidays] 14 days no updates: 14th to end of July

[Marcus Denker]

Hi,

We just saw that everyone who can press the button for a final integration
will be on Holidays from July 14 to the end of the month.

This means there will be no update, but the issue tracker will stay open of 
course,
so issues can be submitted, fixed and reviewed… they will just not end up the 
downloadable
image for that 2 weeks.

Marcus

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

[stepharo]

Do you think professional developers who use Pharo all day like crashes or 
hangs ? We are all the same here, we want a stable system.

It is not certain that the catalog download is the problem.

This specific feature that you think should only be enabled by those who want 
it (you call them pros) is exactly a beginner's feature: a way to discover 
every external library written. How ironic that you don't care.

Sven the students we have are not looking for published packages and if they 
need, they can use the catalog: entering XML and pressing ok
there is simple enough. It is not a complex ui. Spotter is a lot more confusing 
than the catalog UI. But dogma says the inverse so I will stop
arguing.

Well, you won, the feature is gone.

No it is not gone.
Update your preferences and help fixing the real problem and we will put 
it back.


You see I produce Spotter videos for the mooc. Do you think that I 
should have spent all this energy for something that I do not like.

Now we should be able to critic features.

Stef

Yes, newcomers hit all kinds of issues that more experienced users 
subconsciously avoid, being mindful for that is important. I think we all try 
to do that, by fixing things, not by turning things off.

We lack a proper process to decide these kinds of conflicts.


On 08 Jul 2016, at 11:21, stepharo  wrote:

Again again and again: How many times do you see students having Pharo frozen 
because the internet connection in the classroom is fleaky.

Apparently turning off these people is not an issue to you. Perfect but it is 
one for me.

For your productivity boost why can't you click on one setting and put it on?

Tell me I do not understand. In my dev image I have several settings set for my 
own usage.

So why you cannot have one extra one? Especially since preferences are loaded 
automatically.


Then when we will find a way to address the real problem we can just turn the 
setting on.

I will have spent half of my life showing software to newbies and may I ask you 
when is the last time

you show Pharo to a guy that is learning programming? I do that often (may be 
too often)

and in bad situation like in Afrika but not only.

Stef



Le 6/7/16 à 20:19, Sven Van Caekenberghe a écrit :

I'll try once more to explain.

You like the catalog, don't you ?  It was your idea in the first place. With 
this feature you can just type XML, CSV, JSON or whatever and it will suggest a 
couple of catalog projects that you can install with just one click, no need to 
open any tool you don't even know. This is especially good for new people. IT 
IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD WORK. It leverages all the 
work put in the catalog.

Is Spotter or any other part of Pharo perfect ? No.

For many people, Spotter make a huge functional difference, we use it every 
minute. If it would hang or block the image even once a day, any of us would 
complain loudly.

Conclusion: it works for 99% of the people/cases.

Even in the 1% where there is a problem, it is not 100% sure it is related to 
the catalog searching. In the last concrete issue reported, the guy tried 
disabling the catalog searching AND IT MADE NO DIFFERENCE !

So again, why turn it off ? It is an overreaction, not engineering.

The underlying problem is that in some very rare, hard to reproduce cases we 
cannot reliably detect that there is no network. That's about it.

Note also that almost every application or app today will do some network 
calls, this is how the world work - we should be able to do the same with 
Pharo, not run away and kill every feature that does a network call.


On 06 Jul 2016, at 18:14, stepharo  wrote:

Who vote to put it in?

Seriously I think that my main concern is about getting Pharo stable in any 
occasion and not giving

a bad impression of the system. I takes enough time to build traction and such 
glitches can spoil

our effort in no time. "Yes Pharo froze."

So it would be nice to care take of such aspect.

I do not understand why super users do not manage to put a reference to on in 
the preferences.

Sorry esteban but I do not buy your argument that something off is remove. No 
it is off.

Stef

On 06 Jul 2016, at 09:52, GitHub  wrote:

18674 Turn spotter catalog off by default
https://pharo.fogbugz.com/f/cases/18674

We did not agree on this, at all, there was no public discussion, no vote.

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

[Sven Van Caekenberghe]

> On 08 Jul 2016, at 12:21, stepharo  wrote:
> 
> 
> 
> Le 8/7/16 à 11:44, Sven Van Caekenberghe a écrit :
>> Do you think professional developers who use Pharo all day like crashes or 
>> hangs ? We are all the same here, we want a stable system.
>> 
>> It is not certain that the catalog download is the problem.
>> 
>> This specific feature that you think should only be enabled by those who 
>> want it (you call them pros) is exactly a beginner's feature: a way to 
>> discover every external library written. How ironic that you don't care.
> 
> Sven the students we have are not looking for published packages and if they 
> need, they can use the catalog: entering XML and pressing ok
> there is simple enough. It is not a complex ui. Spotter is a lot more 
> confusing than the catalog UI. But dogma says the inverse so I will stop
> arguing.

Well, you won, the feature is gone.

>> 
>> Yes, newcomers hit all kinds of issues that more experienced users 
>> subconsciously avoid, being mindful for that is important. I think we all 
>> try to do that, by fixing things, not by turning things off.
>> 
>> We lack a proper process to decide these kinds of conflicts.
>> 
>>> On 08 Jul 2016, at 11:21, stepharo  wrote:
>>> 
>>> Again again and again: How many times do you see students having Pharo 
>>> frozen because the internet connection in the classroom is fleaky.
>>> 
>>> Apparently turning off these people is not an issue to you. Perfect but it 
>>> is one for me.
>>> 
>>> For your productivity boost why can't you click on one setting and put it 
>>> on?
>>> 
>>> Tell me I do not understand. In my dev image I have several settings set 
>>> for my own usage.
>>> 
>>> So why you cannot have one extra one? Especially since preferences are 
>>> loaded automatically.
>>> 
>>> 
>>> Then when we will find a way to address the real problem we can just turn 
>>> the setting on.
>>> 
>>> I will have spent half of my life showing software to newbies and may I ask 
>>> you when is the last time
>>> 
>>> you show Pharo to a guy that is learning programming? I do that often (may 
>>> be too often)
>>> 
>>> and in bad situation like in Afrika but not only.
>>> 
>>> Stef
>>> 
>>> 
>>> 
>>> Le 6/7/16 à 20:19, Sven Van Caekenberghe a écrit :
 I'll try once more to explain.
 
 You like the catalog, don't you ?  It was your idea in the first place. 
 With this feature you can just type XML, CSV, JSON or whatever and it will 
 suggest a couple of catalog projects that you can install with just one 
 click, no need to open any tool you don't even know. This is especially 
 good for new people. IT IS A FANTASTIC FEATURE, IT IS THE WAY THINGS 
 SHOULD WORK. It leverages all the work put in the catalog.
 
 Is Spotter or any other part of Pharo perfect ? No.
 
 For many people, Spotter make a huge functional difference, we use it 
 every minute. If it would hang or block the image even once a day, any of 
 us would complain loudly.
 
 Conclusion: it works for 99% of the people/cases.
 
 Even in the 1% where there is a problem, it is not 100% sure it is related 
 to the catalog searching. In the last concrete issue reported, the guy 
 tried disabling the catalog searching AND IT MADE NO DIFFERENCE !
 
 So again, why turn it off ? It is an overreaction, not engineering.
 
 The underlying problem is that in some very rare, hard to reproduce cases 
 we cannot reliably detect that there is no network. That's about it.
 
 Note also that almost every application or app today will do some network 
 calls, this is how the world work - we should be able to do the same with 
 Pharo, not run away and kill every feature that does a network call.
 
> On 06 Jul 2016, at 18:14, stepharo  wrote:
> 
> Who vote to put it in?
> 
> Seriously I think that my main concern is about getting Pharo stable in 
> any occasion and not giving
> 
> a bad impression of the system. I takes enough time to build traction and 
> such glitches can spoil
> 
> our effort in no time. "Yes Pharo froze."
> 
> So it would be nice to care take of such aspect.
> 
> I do not understand why super users do not manage to put a reference to 
> on in the preferences.
> 
> Sorry esteban but I do not buy your argument that something off is 
> remove. No it is off.
> 
> Stef
>>> On 06 Jul 2016, at 09:52, GitHub  wrote:
>>> 
>>> 18674 Turn spotter catalog off by default
>>> https://pharo.fogbugz.com/f/cases/18674
>> We did not agree on this, at all, there was no public discussion, no 
>> vote.
>> 
>> 
 
>>> 
>> 
>> 
> 
> 

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

[stepharo]

Le 8/7/16 à 11:44, Sven Van Caekenberghe a écrit :

Do you think professional developers who use Pharo all day like crashes or 
hangs ? We are all the same here, we want a stable system.

It is not certain that the catalog download is the problem.

This specific feature that you think should only be enabled by those who want 
it (you call them pros) is exactly a beginner's feature: a way to discover 
every external library written. How ironic that you don't care.


Sven the students we have are not looking for published packages and if 
they need, they can use the catalog: entering XML and pressing ok
there is simple enough. It is not a complex ui. Spotter is a lot more 
confusing than the catalog UI. But dogma says the inverse so I will stop

arguing.



Yes, newcomers hit all kinds of issues that more experienced users 
subconsciously avoid, being mindful for that is important. I think we all try 
to do that, by fixing things, not by turning things off.

We lack a proper process to decide these kinds of conflicts.


On 08 Jul 2016, at 11:21, stepharo  wrote:

Again again and again: How many times do you see students having Pharo frozen 
because the internet connection in the classroom is fleaky.

Apparently turning off these people is not an issue to you. Perfect but it is 
one for me.

For your productivity boost why can't you click on one setting and put it on?

Tell me I do not understand. In my dev image I have several settings set for my 
own usage.

So why you cannot have one extra one? Especially since preferences are loaded 
automatically.


Then when we will find a way to address the real problem we can just turn the 
setting on.

I will have spent half of my life showing software to newbies and may I ask you 
when is the last time

you show Pharo to a guy that is learning programming? I do that often (may be 
too often)

and in bad situation like in Afrika but not only.

Stef



Le 6/7/16 à 20:19, Sven Van Caekenberghe a écrit :

I'll try once more to explain.

You like the catalog, don't you ?  It was your idea in the first place. With 
this feature you can just type XML, CSV, JSON or whatever and it will suggest a 
couple of catalog projects that you can install with just one click, no need to 
open any tool you don't even know. This is especially good for new people. IT 
IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD WORK. It leverages all the 
work put in the catalog.

Is Spotter or any other part of Pharo perfect ? No.

For many people, Spotter make a huge functional difference, we use it every 
minute. If it would hang or block the image even once a day, any of us would 
complain loudly.

Conclusion: it works for 99% of the people/cases.

Even in the 1% where there is a problem, it is not 100% sure it is related to 
the catalog searching. In the last concrete issue reported, the guy tried 
disabling the catalog searching AND IT MADE NO DIFFERENCE !

So again, why turn it off ? It is an overreaction, not engineering.

The underlying problem is that in some very rare, hard to reproduce cases we 
cannot reliably detect that there is no network. That's about it.

Note also that almost every application or app today will do some network 
calls, this is how the world work - we should be able to do the same with 
Pharo, not run away and kill every feature that does a network call.


On 06 Jul 2016, at 18:14, stepharo  wrote:

Who vote to put it in?

Seriously I think that my main concern is about getting Pharo stable in any 
occasion and not giving

a bad impression of the system. I takes enough time to build traction and such 
glitches can spoil

our effort in no time. "Yes Pharo froze."

So it would be nice to care take of such aspect.

I do not understand why super users do not manage to put a reference to on in 
the preferences.

Sorry esteban but I do not buy your argument that something off is remove. No 
it is off.

Stef

On 06 Jul 2016, at 09:52, GitHub  wrote:

18674 Turn spotter catalog off by default
https://pharo.fogbugz.com/f/cases/18674

We did not agree on this, at all, there was no public discussion, no vote.

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

[Sven Van Caekenberghe]

Do you think professional developers who use Pharo all day like crashes or 
hangs ? We are all the same here, we want a stable system.

It is not certain that the catalog download is the problem.

This specific feature that you think should only be enabled by those who want 
it (you call them pros) is exactly a beginner's feature: a way to discover 
every external library written. How ironic that you don't care.

Yes, newcomers hit all kinds of issues that more experienced users 
subconsciously avoid, being mindful for that is important. I think we all try 
to do that, by fixing things, not by turning things off.

We lack a proper process to decide these kinds of conflicts.

> On 08 Jul 2016, at 11:21, stepharo  wrote:
> 
> Again again and again: How many times do you see students having Pharo frozen 
> because the internet connection in the classroom is fleaky.
> 
> Apparently turning off these people is not an issue to you. Perfect but it is 
> one for me.
> 
> For your productivity boost why can't you click on one setting and put it on?
> 
> Tell me I do not understand. In my dev image I have several settings set for 
> my own usage.
> 
> So why you cannot have one extra one? Especially since preferences are loaded 
> automatically.
> 
> 
> Then when we will find a way to address the real problem we can just turn the 
> setting on.
> 
> I will have spent half of my life showing software to newbies and may I ask 
> you when is the last time
> 
> you show Pharo to a guy that is learning programming? I do that often (may be 
> too often)
> 
> and in bad situation like in Afrika but not only.
> 
> Stef
> 
> 
> 
> Le 6/7/16 à 20:19, Sven Van Caekenberghe a écrit :
>> I'll try once more to explain.
>> 
>> You like the catalog, don't you ?  It was your idea in the first place. With 
>> this feature you can just type XML, CSV, JSON or whatever and it will 
>> suggest a couple of catalog projects that you can install with just one 
>> click, no need to open any tool you don't even know. This is especially good 
>> for new people. IT IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD WORK. 
>> It leverages all the work put in the catalog.
>> 
>> Is Spotter or any other part of Pharo perfect ? No.
>> 
>> For many people, Spotter make a huge functional difference, we use it every 
>> minute. If it would hang or block the image even once a day, any of us would 
>> complain loudly.
>> 
>> Conclusion: it works for 99% of the people/cases.
>> 
>> Even in the 1% where there is a problem, it is not 100% sure it is related 
>> to the catalog searching. In the last concrete issue reported, the guy tried 
>> disabling the catalog searching AND IT MADE NO DIFFERENCE !
>> 
>> So again, why turn it off ? It is an overreaction, not engineering.
>> 
>> The underlying problem is that in some very rare, hard to reproduce cases we 
>> cannot reliably detect that there is no network. That's about it.
>> 
>> Note also that almost every application or app today will do some network 
>> calls, this is how the world work - we should be able to do the same with 
>> Pharo, not run away and kill every feature that does a network call.
>> 
>>> On 06 Jul 2016, at 18:14, stepharo  wrote:
>>> 
>>> Who vote to put it in?
>>> 
>>> Seriously I think that my main concern is about getting Pharo stable in any 
>>> occasion and not giving
>>> 
>>> a bad impression of the system. I takes enough time to build traction and 
>>> such glitches can spoil
>>> 
>>> our effort in no time. "Yes Pharo froze."
>>> 
>>> So it would be nice to care take of such aspect.
>>> 
>>> I do not understand why super users do not manage to put a reference to on 
>>> in the preferences.
>>> 
>>> Sorry esteban but I do not buy your argument that something off is remove. 
>>> No it is off.
>>> 
>>> Stef
> On 06 Jul 2016, at 09:52, GitHub  wrote:
> 
> 18674 Turn spotter catalog off by default
>   https://pharo.fogbugz.com/f/cases/18674
 We did not agree on this, at all, there was no public discussion, no vote.
 
 
>>> 
>> 
>> 
> 
> 

Re: [Pharo-dev] [pharo-project/pharo-core] a813b2: 60138

[stepharo]

Le 6/7/16 à 18:52, Marcus Denker a écrit :

On 06 Jul 2016, at 18:16, stepharo  wrote:

I always found such kind of changes totally obscure and it would be nice to 
have a description.



Fixes issues:

- 18450 GT-Tools: "Do not use #ifNotNilDo:ifNil:, #ifNil:ifNotNilDo:, 
#ifNotNilDo:"
- 18453 GT-Tools: "do not use #ifEmpty:ifNotEmptyDo: #ifNotEmptyDo: 
#ifNotEmptyDo:ifEmpty:”
- 18431 attach glmpopplers shortcut to the textarea instead of the scroll pane
- Esteban's change to GLMAction

This was mostly me pushing for getting the trivial things *DONE* and not wait 
another 3 weeks…

Great.
I love this runtime deprecation transform it will really help us to move 
faster.

Tx for building it. I love it. :)


(I should have just committed slices, the overhead with committing and syncing 
is to high for
trivial refactorings)

Yes :)
I hope one day (soon) we will be able to get a lot faster on our 
pullrequests.

Marcus

Re: [Pharo-dev] [squeak-dev] Time now print24

[Sven Van Caekenberghe]

> On 08 Jul 2016, at 10:49, Tobias Pape  wrote:
> 
> 
> On 07.07.2016, at 18:33, Eliot Miranda  wrote:
> 
>> Hi All,
>> 
>>how does one produce a nice timestamp, simply date and time as in
>> 
>>7/7/2016 09:19:38
> 
> What's with 'TimeStamp now'  (prints  '8 July 2016 10:34:36 am')
> 
> or this one:
> 
> TimeStamp now in: [:t |
>   String streamContents: [:s |
>   t asDate printOn: s format: #(2 1 3 $/ 1 1 2).
>   s space.
>   t asTime print24: true showSeconds: true on: s]]
> 
> Too bad TimeStamp is deprecated in Pharo4, so this works in pharo:

Yes, it is gone. It was a subclass whose only feature was a different print 
representation. It was also confusing, why choose it or DateAndTime.

We folded TimeStamp's functionality into DateAndTime (see 
#printSeparateDateAndTimeOn: and #readSeparateDateAndTimeFrom:)

> DateAndTime now rounded in: [:t |
>   String streamContents: [:s |
>   t asDate printOn: s format: #(2 1 3 $/ 1 1 2).
>   s space.
>   t asTime print24: true showSeconds: true on: s]]
> 
> But DateAndTime knows no #rounded in Squeak, buuut:
> 
>> ===
> 
> This works for both:
> 
> 
> DateAndTime now in: [:t |
>   String streamContents: [:s |
>   t asDate printOn: s format: #(2 1 3 $/ 1 1 2).
>   s space.
>   t printHMSOn: s]]
> 
> =
> 
> Best regards
>   -Tobias
> 
> PS: I'd prefer ISO, nonetheless: https://xkcd.com/1179/

Yes, that was my point exactly. Thanks for the cool link!

In the same line, the AM/PM don't make sense, and the timezone (or Z) is 
required.

https://en.wikipedia.org/wiki/ISO_8601

Something like 2016-07-08 08:41:52 Z or 2016-07-08 08:41:52 +00:00 is perfectly 
readable.

BTW, these are unambigiously parseable as well (for example, using ZTimestamp).

ZTimestamp readFromString: '2016-07-08 08:41:52 Z'. 

"2016-07-08T08:41:52Z"

ZTimestamp readFromString: '2016-07-08 08:41:52 +00:00'. 

"2016-07-08T08:41:52Z"

Using ZTimestampFormat, which is an example based formatter/parser, like Go's, 
you can easily produce this slightly more human friendly format.

(ZTimestampFormat fromString: '2001-02-03 16:05:06 +00:00') format: DateAndTime 
now. 

"'2016-07-08 11:16:54 +02:00'"

And the reverse (obviously you share/predefine/cache the specific format 
object).

(ZTimestampFormat fromString: '2001-02-03 16:05:06 +00:00') createDateAndTime; 
parse: '2016-07-08 11:16:54 +02:00'. 

"2016-07-08T11:16:54+02:00"

>   (or the German way: 25.12.2015 :P)
> 
> 
> 
>> 
>> Trivial, right?
>> 
>> So
>> 
>>Date today mmdd, ' ', Time now print24 '7/7/2016 09:22:40.914'
>> 
>> .914, ah, nanos.  How useful.  Let's get rid of them.  No nanos: accessor so
>> 
>>Date today mmdd, ' ', (Time now nanos: 0) print24 => MNU
>> 
>> but there's a seconds accessor, so
>> 
>>Date today mmdd, ' ', (Time now seconds: Time now seconds; print24) 
>> '7/7/2016 00:00:41
>> 
>> ??  So seconds: is private, and isn't the dual of Time seconds:
>> 
>> Time seconds
>>  ^ self second
>> Time second
>>  ^ self asDuration seconds
>> Duration seconds
>>  "Answer the number of seconds the receiver represents."
>>  ^seconds rem: SecondsInMinute
>> 
>> Looks broken to me.
>> 
>> Personally I think print24 should not print sub seconds.
>> 
>> cc'ing to Pharo because I want this timestamp to be the same in both 
>> dialects for a profiling tool we want to use in both dialects.
>> _,,,^..^,,,_
>> best, Eliot
> 
> 
> 

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

[stepharo]

Again again and again: How many times do you see students having Pharo 
frozen because the internet connection in the classroom is fleaky.


Apparently turning off these people is not an issue to you. Perfect but 
it is one for me.


For your productivity boost why can't you click on one setting and put 
it on?


Tell me I do not understand. In my dev image I have several settings set 
for my own usage.


So why you cannot have one extra one? Especially since preferences are 
loaded automatically.



Then when we will find a way to address the real problem we can just 
turn the setting on.


I will have spent half of my life showing software to newbies and may I 
ask you when is the last time


you show Pharo to a guy that is learning programming? I do that often 
(may be too often)


and in bad situation like in Afrika but not only.

Stef



Le 6/7/16 à 20:19, Sven Van Caekenberghe a écrit :

I'll try once more to explain.

You like the catalog, don't you ?  It was your idea in the first place. With 
this feature you can just type XML, CSV, JSON or whatever and it will suggest a 
couple of catalog projects that you can install with just one click, no need to 
open any tool you don't even know. This is especially good for new people. IT 
IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD WORK. It leverages all the 
work put in the catalog.

Is Spotter or any other part of Pharo perfect ? No.

For many people, Spotter make a huge functional difference, we use it every 
minute. If it would hang or block the image even once a day, any of us would 
complain loudly.

Conclusion: it works for 99% of the people/cases.

Even in the 1% where there is a problem, it is not 100% sure it is related to 
the catalog searching. In the last concrete issue reported, the guy tried 
disabling the catalog searching AND IT MADE NO DIFFERENCE !

So again, why turn it off ? It is an overreaction, not engineering.

The underlying problem is that in some very rare, hard to reproduce cases we 
cannot reliably detect that there is no network. That's about it.

Note also that almost every application or app today will do some network 
calls, this is how the world work - we should be able to do the same with 
Pharo, not run away and kill every feature that does a network call.


On 06 Jul 2016, at 18:14, stepharo  wrote:

Who vote to put it in?

Seriously I think that my main concern is about getting Pharo stable in any 
occasion and not giving

a bad impression of the system. I takes enough time to build traction and such 
glitches can spoil

our effort in no time. "Yes Pharo froze."

So it would be nice to care take of such aspect.

I do not understand why super users do not manage to put a reference to on in 
the preferences.

Sorry esteban but I do not buy your argument that something off is remove. No 
it is off.

Stef

On 06 Jul 2016, at 09:52, GitHub  wrote:

18674 Turn spotter catalog off by default
https://pharo.fogbugz.com/f/cases/18674

We did not agree on this, at all, there was no public discussion, no vote.

Re: [Pharo-dev] lineConversion for WriteStream

[monty]

If you upgrade XMLParser, the DOM file printing methods like printToFileNamed: 
now automatically use your OS's linebreak, and XMLWriter, which always allowed 
setting the linebreak, now has an option to detect your OS's linebreak and use 
that.

Sent: Thursday, May 26, 2016 at 2:20 PM
From: "Peter Uhnák" 
To: "Pharo Development List" 
Subject: Re: [Pharo-dev] lineConversion for WriteStream

Well I was saving e.g. STON or XML file… but some apps outside didn't 
particularly like it… even `cat` doesn't like CR.
Anyway; this is not system-breaking problem, just annoying.
 
Peter
 
On Thu, May 26, 2016 at 2:50 PM, Sven Van Caekenberghe  wrote:

> On 26 May 2016, at 14:06, Peter Uhnák  
> wrote:
>
>
>
> On Thu, May 26, 2016 at 1:40 PM, Sven Van Caekenberghe 
>  wrote:
>
> > On 26 May 2016, at 13:29, Peter Uhnák 
> >  wrote:
> >
> > >  In general I would say that you should write either something platform 
> > >specific or you write something specific
> >
> > Except that I cannot do that because the system doesn't support neither.
> > And the fact that the default line ending is CR is just bullshit… it's 
> > 2016, not 1986.
>
> Yes, that CR is from days long gone ;-)
>
> > or #cr #lf or #crlf as needed, and/or make that last one a parameter 
> > (OSPlatform current lineEnding).
>
> I am piping unknown content into the file, thus the need for 
> `lineEndConvention:` and the reason of this entire thread. So as I said, the 
> system doesn't support it.
> I know I can use #lf or whatnot, but I am not creating the content, I am 
> saving it.
>
> Peter
 Well, maybe I don't understand your use case, but if you do not know what is 
inside, why not save it as is, binary even, not doing any conversions ?

 

Re: [Pharo-dev] Having comments for pragma?

[Tudor Girba]

Hi,

Ok, great. I will play with this.

Cheers,
Doru


> On Jul 7, 2016, at 11:19 PM, Eliot Miranda  wrote:
> 
> Hi Doru,
> 
>> On Jun 30, 2016, at 1:08 PM, Tudor Girba  wrote:
>> 
>> Hi,
>> 
>>> On Jun 27, 2016, at 7:55 PM, Eliot Miranda  wrote:
>>> 
>>> Hi Doru,
>>> 
>>> On Mon, Jun 27, 2016 at 6:36 AM, Tudor Girba  wrote:
>>> Hi Eliot,
>>> 
>>> I agree with most things you say (except the conclusion :)), and I think 
>>> that we are talking about complementary issues.
>>> 
>>> As I mentioned before, there already is a need to distinguish between a 
>>> plain selector and one that is associated with pragmas. This is what you 
>>> find in PragmaType in Spotter and Inspector. This is a kind of meta-object 
>>> and having it adds value. I can search for pragmas “type” (we can also call 
>>> it a PragmaSelector), and I can distinguish between all occurrences of a 
>>> pragma “type” and its utilization in computation. But, the current 
>>> implementation of PragmaType is a mere pseudo-meta-object, given that it 
>>> has no casual connection to the runtime.
>>> 
>>> What we know from Smalltalk is that the analysis model does not have to 
>>> differ from the runtime one. The consequence is that every time we do see a 
>>> difference, we should investigate because we might uncover a hidden need 
>>> opportunity.
>>> 
>>> I know the VW model, and indeed, we could have something like:
>>> 
>>> MyConcept class>>myPragmaDefinition
>>>   “a comment about the pragma"
>>>   
>>> 
>>> However, this only deals with the definition of the pragma type not with 
>>> the internal representation. There could still well be an object that 
>>> encapsulates both the selector and the comment. And that object would also 
>>> allow us to build tools around it. We could call it a PragmaType, 
>>> PragmaDefinition, or even PragmaSelector. And we could get the Pragma to 
>>> point to this type either through an inst var or through a query (I would 
>>> probably prefer an instvar).
>>> 
>>> Well, there already /is/ a meta-object called Pragma, and it gets 
>>> instantiated when one accesses the compiled method via pragmas:
>>> 
>>> (CompiledMethod allInstances detect: [:m| m pragmas size > 1]) pragmas 
>>> collect: [:ea| {ea. ea class}] {{ . Pragma} . {>> #tablePtr type: 'int *'> . Pragma}}
>> 
>> Yes I know :). An instance of Pragma denotes an concrete annotation of a 
>> method. I now would like a meta-object that describes all Pragma instances 
>> having the same selector. For example, the protocol on the class side of the 
>> Pragma class is actually a query protocol that is better suited for the 
>> instance side of a PragmaDescription meta-object. For example:
>> 
>>   Pragma class>>allNamed: aSymbol in: aClass
>> 
>> would become
>> 
>>   PragmaDescription>>pragmasIn: aClass
>> 
>> and you would use it like:
>> 
>>   (PragmaDescription named: aSymbol) pragmasIn: aClass
>> 
>> Creating an instance of PragmaDescription would imply searching the image 
>> for the  definition.
> 
> I like this.
> 
>> I would also like to have a Flyweight pool per environment such that we 
>> always get only one instance of a PragmaDefinition per selector (like it 
>> happens with Symbols).
> 
> Yes, good refinement.
> 
>>> So we could add the information you want to Pragma, and have it be lazy.
>> 
>> It does not quite belong to the Pragma. A comment is common to all Pragma 
>> instances, and having it duplicated at the instance level is less elegant.
>> 
>> But, looking for the users (all senders of the pragma selector - the methods 
>> that use the annotation) of a Pragma would be even less inconvenient to have 
>> on the instance side of Pragma.
>> 
>> 
>>> The Pragma could go search for the defining class-side pragma methods and 
>>> use the parser to extract the comment(s) when asked.  Hence simple access 
>>> to pragmas, interested only in the selectors for applying, wouldn't have 
>>> their performance be impacted.
>> 
>> The design sketched above would require no runtime penalty for a Pragma 
>> instance. All code that works now would work identically afterwards. We 
>> would only have one selector in Pragma to get the corresponding description:
>> 
>> Pragma>>description
>>   ^ PragmaDescription named: self selector
>> 
>> Alternatively, we could modify the compilation to associate the 
>> PragmaDescription in an inst var of a Pragma instance. So, 
>> CompiledMethod>>pragmas would always return instances of Pragmas with a 
>> PragmaDefinition inst var.
>> 
>> I think I would start with the lazy lookup first, and this would disturb 
>> nothing from the current behavior.
> 
> Sounds like a reasonable plan.  
> 
>> 
>> 
>>> I think that this proposition does not remove from the simplicity of the 
>>> implementation at all, but allows the new needs to be accommodated nicely. 
>>> The alternative is to not do anything, in which case we will