Re: [Pharo-dev] red banner and links with safari?

On 22-11-15 23:53, Ben Coman wrote: I guess the only real fix for the https pages produced to reference https stylesheets. cheers -ben On Mon, Nov 23, 2015 at 1:58 AM, Peter Uhnák > wrote: > The question now is: what do we need to fix to make it

Re: [Pharo-dev] red banner and links with safari?

I guess the only real fix for the https pages produced to reference https stylesheets. cheers -ben On Mon, Nov 23, 2015 at 1:58 AM, Peter Uhnák wrote: > > The question now is: what do we need to fix to make it work? > > > ​ > (or just open console in your favorite browser

Re: [Pharo-dev] Does Pharo stores original author of methods?

Is there any reason against amending Monticello to store and save all author's names? Presumably, we'd also want a tool that could extract amnders' names all the way back to the first commit of a package? How many on-line Monticello repositories are in common use? (I know of SqueakSource.com,

Re: [Pharo-dev] Kind of RBRenameMethodRefactoring but for closures?

> > >> >> Yes. I think it is possible to work around it by using the >> dictionary itself, storing the node selector in it in the replace: >> pattern and retrieving it in the with: pattern. >> >> rewriter >> replace: ('`#oldSelector `{:node :dic | (node value

Re: [Pharo-dev] A plea for responsive coding

But why don't you manipulate Forms instead of PNGs. Converting from PNGs to Forms should be done only once. Stef Le 22/11/15 11:53, Dimitris Chloupis a écrit : here is the tricky part , I am willing to bet that the slow down happens because of the stepping of the seconds indicator. The one

Re: [Pharo-dev] A plea for responsive coding

because making something work for me comes way before making something work fast. On Sun, Nov 22, 2015 at 3:50 PM stepharo wrote: > But why don't you manipulate Forms instead of PNGs. Converting from PNGs > to Forms should be done only once. > > Stef > > Le 22/11/15 11:53,

Re: [Pharo-dev] Digest from slack to the mailing list?

Just to clear something up , because I see people in slack saying goodbye, or "I cant reply right now I have something to do" . Slack is not just a real time chat, it keeps messages inside a history of 10 thousand messages. So that means you can log in Slack at any time and not lose a message.

Re: [Pharo-dev] A plea for responsive coding

This is not a point to make thing fast this is make things right :) PNG are not graphical pharo objects, only forms. Stef Le 22/11/15 14:56, Dimitris Chloupis a écrit : because making something work for me comes way before making something work fast. On Sun, Nov 22, 2015 at 3:50 PM stepharo

Re: [Pharo-dev] A plea for responsive coding

really you ask me why I am complaining that loading a form from a 2kb png image, AND I REPEAT , 2KB IMAGE ,for each morphic step brings a whole GUI system to its knees with 5 instances ? I complain, which I did not complain by the way but your post inspires me to complain a lot now, because

Re: [Pharo-dev] red banner and links with safari?

Oh, This explains it… Before upping MacOS, I tuned on SSL via cloud flare (part of a “SSL everywhere” initiative…). It seemed to work nicely. But now in the new Safari, it seems that they stop loading non-ssl resources when you request the main page via SSL… The question now is: what do we

Re: [Pharo-dev] recompiling all classes and traits is slow (at least on windows)

Wow, I did not know you can close and open source files. Everyday there is something to learn. Cheers, Alexandre > On Nov 22, 2015, at 8:16 AM, Max Leske wrote: > > If you only need it for yourself you could probably speed things up by doing > > Smalltalk

Re: [Pharo-dev] A plea for responsive coding

+10 Stef Hi all, I would like to ask you, all of you, something significant when doing GUI coding: Pay attention to performance! With the current state of our technology (Morphic, Bloc, whatever comes next) your target should be one hundred milliseconds (100 ms), for opening /

[Pharo-dev] [pharo-project/pharo-core] a4ba46: 50457

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: a4ba46aa059cc15f4892e91086abcdec33c4c677 https://github.com/pharo-project/pharo-core/commit/a4ba46aa059cc15f4892e91086abcdec33c4c677 Author: Jenkins Build Server Date:

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

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

Re: [Pharo-dev] A plea for responsive coding

You should relax a bit. We were trying to help. Morphic is slow and strange and we are working on new generation. Now profile a bit your application to see what you are doing may be you are redrawing too much or triggering something that is costly. So it depends what you are doing. the step

Re: [Pharo-dev] A plea for responsive coding

I realize you trying to help, and thank you very much. Nothing I have done would be possible without your help. But also you must realize I am not you and not as familiar with Pharo as you are. Also when I say that I do something that does not mean I ignore your advice. At the moment I was not

Re: [Pharo-dev] recompiling all classes and traits is slow (at least on windows)

> On 22 Nov 2015, at 10:42, Alexandre Bergel wrote: > > Wow, I did not know you can close and open source files. > Everyday there is something to learn. > It does not look like something you are supposed to know… or do. There are multiple things that are just not

Re: [Pharo-dev] Does Pharo stores original author of methods?

> On 20 Nov 2015, at 14:35, Denis Kudriashov wrote: > > > 2015-11-20 14:21 GMT+01:00 Marcus Denker >: > epicea data is not stored forever. It is seasion based and the shipped image > is > clean. > > But current

Re: [Pharo-dev] Digest from slack to the mailing list?

Yes this would be good. People should understand that important discussions should be via the mailing-list. Emails are good because you can consume them the way you want. I simply cannot be connected all the time. So emails are good because I can process them when I decide. Slack is good for

Re: [Pharo-dev] A plea for responsive coding

sorry Stef I dont understand what you trying to say. As I already said I am not even using PNGs, they are converted to stream strings that then are converted to forms. By the time my objects are initialised those images are already stream strings and during initialisation are converted to forms

Re: [Pharo-dev] A plea for responsive coding

Then why do you “complain" about the code being slow? :) Seriously, how do you store the PNG file in the method? Here is an example of how to store the form of a PNG: form := PNGReadWriter formFromFileNamed: aPngFile. iconName := aPngFile basenameWithoutExtension. methodSource :=

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

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

[Pharo-dev] Rules

With the following (broken) definition printOn: aStream super printOn: aStream aStream nextPutAll: '(', faces printString , ')' I got this strange rule: Rewrite super messages to self messages when both refer to same method I do not get it and it looks really suspicious to me.

Re: [Pharo-dev] Rules

> On 22 Nov 2015, at 12:20, stepharo wrote: > > With the following (broken) definition > > > : aStream >super printOn: aStream >aStream nextPutAll: '(', faces printString , ')' > > I got this strange rule: > >Rewrite super messages to self messages when both

Re: [Pharo-dev] recompiling all classes and traits is slow (at least on windows)

That is better, 5 minutes instead of 15 ! 2015-11-22 12:16 GMT+01:00 Max Leske : > If you only need it for yourself you could probably speed things up by > doing > > Smalltalk closeSourceFiles. [ compile… ] ensure: [ Smalltalk > openSourceFiles ]. > > That will prevent reads

Re: [Pharo-dev] A plea for responsive coding

Le 22/11/2015 11:27, Dimitris Chloupis a écrit : tried with ChronosManager [ ChronosManager open ] bench 5.6 per second it opened around 30 instances and Morphic was crawling. I profiled it and it reports that it spends a total 170ms which is consistent with bench. Around 50ms is spent only

Re: [Pharo-dev] Digest from slack to the mailing list?

I don’t think that’s necessary. Important stuff will still be sent via mail and be documented in issues on fogbugz. That’s my personal feeling at least. Cheers, Max > On 21 Nov 2015, at 18:05, Stephan Eggermont wrote: > > Should we have a digest from slack to a mailing list?

Re: [Pharo-dev] Digest from slack to the mailing list?

I think its important to have, I have already learned a ton via Slack and I have marked several posts there are favorites so that I wont lose them . The Slack experiment, even though I have been very skeptical at first, has been a huge success and it can easily compete with the importance of the

Re: [Pharo-dev] A plea for responsive coding

tried with ChronosManager [ ChronosManager open ] bench 5.6 per second it opened around 30 instances and Morphic was crawling. I profiled it and it reports that it spends a total 170ms which is consistent with bench. Around 50ms is spent only for loading the image of the secondary panel and

Re: [Pharo-dev] A plea for responsive coding

here is the tricky part , I am willing to bet that the slow down happens because of the stepping of the seconds indicator. The one thing I forgot to mention is that I dont load my images from external files, the images are already converted to method sources , strings , with Peter's IconFactory

Re: [Pharo-dev] recompiling all classes and traits is slow (at least on windows)

If you only need it for yourself you could probably speed things up by doing Smalltalk closeSourceFiles. [ compile… ] ensure: [ Smalltalk openSourceFiles ]. That will prevent reads and writes from and to the changes / sources files. Of course, that doesn’t solve the problem in general. Cheers,

Re: [Pharo-dev] Digest from slack to the mailing list?

Honestly, who has the time to read all this? I never read the old discussions that happened when I was off in Slack. (And I try to not read everything on this list, too). Just because if I would read everything, I would not have the time to actually *do* anything. Marcus > On 22 Nov

Re: [Pharo-dev] Digest from slack to the mailing list?

On 22/11/15 13:26, Marcus Denker wrote: Honestly, who has the time to read all this? That's not the point. The importance is searchability. It is essential to be able to follow design discussions from 10-15 years ago to understand how to fix things now. That information needs to be openly

Re: [Pharo-dev] Digest from slack to the mailing list?

On 22/11/15 12:14, Max Leske wrote: I don’t think that’s necessary. Important stuff will still be sent via mail and be documented in issues on fogbugz. That’s my personal feeling at least. I don't see that happening at all. We don't publish design notes (abstracts from design discussions)

Re: [Pharo-dev] Kind of RBRenameMethodRefactoring but for closures?

On Sat, Nov 21, 2015 at 7:07 AM, Thierry Goubier wrote: > Hi Mariano, > > Le 20/11/2015 20:58, Mariano Martinez Peck a écrit : > >> Thierry, >> >> Sorry to bother again. Unfortunately, RB does not work out of the box in >> GemStone only the formatter part. grrr.

Re: [Pharo-dev] Rules

>> printOn: aStream >>super printOn: aStream >>aStream nextPutAll: '(', faces printString , ')' Because you forgot dot after the first line. This is why I always use autoformatting to catch these kind of stupid mistakes (happens to me a lot).

[Pharo-dev] Jenkins job @ ci.inria.fr

Hi everyone I have two jobs in ci.inria.fr for the project Tracks. One is for Pharo 3.0 and another for Pharo 4.0. Since Tracks requires Epicea to run and Epicea is no longer mantained for Pharo 3.0, the Tracks job for Pharo 3.0 is failing and it doesn't make sense to keep it. I only want to keep

Re: [Pharo-dev] Rules

Hi. The rule is correct. Sending a different message to super may be confusing. In this case you are in “printOn:” method and you are sending “printOn:nextPutAll:” to super. The idea is that you have to send “printOn:nextPutAll:” to self and then either it will invoke the super one, you there

Re: [Pharo-dev] Kind of RBRenameMethodRefactoring but for closures?

Le 22/11/2015 19:56, Mariano Martinez Peck a écrit : On Sat, Nov 21, 2015 at 7:07 AM, Thierry Goubier > wrote: Hi Mariano, Le 20/11/2015 20:58, Mariano Martinez Peck a écrit : Thierry, Sorry to bother