Re: [Pharo-dev] About Pharo 60

Thanks Cyril Now we have to check what is synectique specific from what should be pushed to Pharo. Since we moved to a Seaside application not so long after I joined Synectique we only disable some basic things. If I don't say anything wrong here is what we did: - Remove repositories

Re: [Pharo-dev] About Pharo 60

Le 27/08/2016 à 14:32, Esteban Lorenzano a écrit : > yes, some years ago I made a package for this. > later Ben tried something similar with the user manager. > none of those approaches worked as general approach because you need to > “close” a lot of things… (not just the spotter… which by the

Re: [Pharo-dev] About Pharo 60

Le 27/08/2016 à 14:39, stepharo a écrit : > Cyril what would be good is to share what you are disabling and to tunr > such points into points that can be turned > but inside Pharo like that you push the logic to the system. > Since we moved to a Seaside application not so long after I joined

Re: [Pharo-dev] About better communication in the community

In context of discussion how to propose Mocketry and StateSpecs to be part of Pharo? We often said that Pharo provides the best approach to TDD but we have no mock library inside. And nobody use mocks for Pharo tests because of that 2016-08-24 6:51 GMT+02:00 stepharo : > Hi

Re: [Pharo-dev] About better communication in the community

2016-08-24 9:38 GMT+02:00 stepharo : > Igor looked at Twisty seriously and I do not think that it could handle > large cobol files. > > (you see funnily denis is doing the same with Seamless - He rewrote it > from scratch while > nick worked on it for several years). >

Re: [Pharo-dev] About better communication in the community

Hi 2016-08-24 18:58 GMT+02:00 Hernán Morales Durand : > 2. Features that goes inside Pharo are not decided by vote. They have to >> add value and share the Pharo vision (pointed in the vision document who is >> not slightly updated but still guides our steps). We try to

Re: [Pharo-dev] About better communication in the community

Hi yuriy A package manifest is the place where we keep package rules and meta data. We should add documentation and others. I think that all the packages should have a XXXManifest. There we can define a method preUnload and after we can define a class PackageUnloader (or put the logic in

Re: [Pharo-dev] About better communication in the community

> On 27 Aug 2016, at 11:00, stepharo wrote: > > You see hernan doing positively is the best way to make that things happen > > We can have a > >preUnload hook > > Now we should check how it fits with cleanForProduction and others. > > But we should definitively have a

Re: [Pharo-dev] About Pharo 60

> On 27 Aug 2016, at 14:40, stepharo wrote: > > Hi esteban > > I think that we should identify the main hook points and slowly prepare them. > > The system should be prepared for that so that we just need to pass a context > to configure it. .. I should have that old

Re: [Pharo-dev] About better communication in the community

So I think that I will keep Eyeinspector for Spec because it works well using Spec. I will package BasicInspector Then we will see. I think that Smalltalk tools inspector is not good because it is yet another global while the tools should have a tool context (but with a registration

Re: [Pharo-dev] About Pharo 60

Hi esteban I think that we should identify the main hook points and slowly prepare them. The system should be prepared for that so that we just need to pass a context to configure it. Stef Le 27/8/16 à 14:32, Esteban Lorenzano a écrit : yes, some years ago I made a package for this.

Re: [Pharo-dev] About Pharo 60

Cyril what would be good is to share what you are disabling and to tunr such points into points that can be turned but inside Pharo like that you push the logic to the system. Now this is important to see that if people for which the value is high do not work on something why others would do

Re: [Pharo-dev] About Pharo 60

yes, some years ago I made a package for this. later Ben tried something similar with the user manager. none of those approaches worked as general approach because you need to “close” a lot of things… (not just the spotter… which by the way, NEEDS to have a setting, no idea who answered you

Re: [Pharo-dev] About Pharo 60

Le 27/08/2016 à 13:18, stepharo a écrit : > > > YES!!! > > Do you know how Settings works? > We can adapt it this way. When I improved the deployment of Synectique Tools I asked to get a simple way to disable Spotter via a setting but I got as answer "No because you can do it by removing a

Re: [Pharo-dev] About Pharo 60

Hi! There is one thing I would like, but maybe not for Pharo6 since there is a lot to do, but I would like people to have this in mind: A way to deploy commercials apps. YES!!! I would like to be able to say something like "Smalltalk lockForDeployment" and "Smalltalk

Re: [Pharo-dev] About Pharo 60

Le 24/08/2016 à 06:59, stepharo a écrit : > Hi > > We have some ideas (because people are working on items) for the Pharo 6 > roadmap > > and we will consolidate them soon and propose them to you. > > but I would like to know two kinds of points > > - what are the points you are working on

Re: [Pharo-dev] About better communication in the community

May be we should take the one of Pharo30 and review all the code. Le 27/8/16 à 10:51, stepharo a écrit : I took the inspector from Pharo20 and I will check if it is working in Pharo. Then I will - check EyeInspector from a package perspective (extensions and the rest) - make sure

Re: [Pharo-dev] About better communication in the community

You see hernan doing positively is the best way to make that things happen We can have a preUnload hook Now we should check how it fits with cleanForProduction and others. But we should definitively have a way to express this. So let us see how we can design it and then just implement

Re: [Pharo-dev] About better communication in the community

I took the inspector from Pharo20 and I will check if it is working in Pharo. Then I will - check EyeInspector from a package perspective (extensions and the rest) - make sure that we can remove EyeInspector - package the attached file as BasicInspector. Now if you want to help

Re: [Pharo-dev] About better communication in the community

What we should do is to add an unload method to each of the package manifest of the corresponding projects. We should make the unload protocol a lot more present. I will start with Nautilus. Can you publish the unload process? Workspace openContents: 'GTPlayground

Re: [Pharo-dev] About better communication in the community

2016-08-26 6:19 GMT-03:00 stepharo : > > About GT I have some concerns too now I see also a lot of improvements. I >> love GTInspector and we should remove EyeInspector. >> >> I want to have once brick is out another minimal environment not based on >> anything so that we can

Re: [Pharo-dev] About asClass and friend

Here is an example where asClass is useful. Someone posts something in the mail list like this... Gofer it smalltalkhubUser: 'hernan' project: 'CodeGenerator'; configuration; loadDevelopment. CGSmalltalkExamples exampleNSISPharo4. and pure laziness (apparently a sign of a good

Re: [Pharo-dev] About better communication in the community

Dne pátek 26. srpna 2016 Hernán Morales Durand napsal(a): > Hi Stef, > > 2016-08-25 3:48 GMT-03:00 stepharo >: > >> Hi hernan >> >> Could you reply to my mail? Because what is important is how we can

Re: [Pharo-dev] About Pharo 60

My Christmas list is divided to 2 sections a) What I want from you b) What I am going to deliver *What I want from you* The things I want from Pharo are centered on the high priorities a) 64 bit version b) Bloc /SDL c) FFI documentation / stabilization Its

Re: [Pharo-dev] About Pharo 60

Le 26/8/16 à 14:40, Norbert Hartl a écrit : Hi, the things I want to have are 64bit, bootstrap and vector graphic backend because these are so disruptive that it takes some time to stabilize the whole system. But there is a roadmap for this which is ok for me. For me we really need to

Re: [Pharo-dev] About Pharo 60

List: * image size management under control Yes it requires to write a new GC so I hope that the VM team with get the ressources. * no more gradients in that UI (even in the light theme) * modern "Material style" UI * FASTER Nautilus what is the problem? * better console support (in/out)

Re: [Pharo-dev] About Pharo 60

Hi, the things I want to have are 64bit, bootstrap and vector graphic backend because these are so disruptive that it takes some time to stabilize the whole system. But there is a roadmap for this which is ok for me. For me we really need to focus on stabilizing a few things which are (to me)

Re: [Pharo-dev] About better communication in the community

So true. :) On Thu, 25 Aug 2016 09:05:45 +0200 stepharo wrote: Yes but we cannot do much OK. I got it...do you believe it makes sense for a noob to create account in case there are some low-hanging fruits to pick? Definitely. And not necessarily that you *solve* an

Re: [Pharo-dev] About better communication in the community

Definitively :) I started to do that when I discovered Smalltalk. I wanted to learn and I read the submissions of people and try to understand and comment. And I learned a lot about the system, about myself, about quality. Stef Le 25/8/16 à 17:31, Gour a écrit : On Thu, 25 Aug 2016

Re: [Pharo-dev] About better communication in the community

About GT I have some concerns too now I see also a lot of improvements. I love GTInspector and we should remove EyeInspector. I want to have once brick is out another minimal environment not based on anything so that we can have a back-door to debug when the other tools have

Re: [Pharo-dev] About Pharo 60

List: * image size management under control * no more gradients in that UI (even in the light theme) * modern "Material style" UI * FASTER Nautilus * better console support (in/out) * Pharo VM as something I can embed in other programs * something like npm.js for the packages list along with

Re: [Pharo-dev] About asClass and friend

On Fri, Aug 26, 2016 at 10:07 AM, Guille Polito wrote: > Hi! > > 1) I think we are failing also at communicating one point better. It is > not that people is arguing against #asClass because it's ugly and bad and a > terrible villain. Ok, maybe a bit, but also: > >

Re: [Pharo-dev] About asClass and friend

On Fri, Aug 26, 2016 at 9:10 AM, Esteban Lorenzano wrote: > > On 26 Aug 2016, at 08:49, Luc Fabresse wrote: > > Hi, > > My point of view is: > > 1) in code/core, we should use (we already said that with Camille in the > past ;-)): > > self

Re: [Pharo-dev] About asClass and friend

On Fri, Aug 26, 2016 at 8:49 AM, Luc Fabresse wrote: > Hi, > > My point of view is: > > 1) in code/core, we should use (we already said that with Camille in the > past ;-)): > > self environmentAt: #Blah > Makes sense, looks nice. > > Object>>environmentAt: aSymbol >

Re: [Pharo-dev] About Pharo 60

Thanks Peter I cannot find the list, but there were some things we discussed during consortium call a month or so ago. Maybe Esteban can find it? I want for Christmas * Better Spec * Roadmap so we know where we are going, * with clean API, * so we can build really live UIs (where you

Re: [Pharo-dev] About asClass and friend

Hi! 1) I think we are failing also at communicating one point better. It is not that people is arguing against #asClass because it's ugly and bad and a terrible villain. Ok, maybe a bit, but also: The point is that #asClass, as it looks handy and easy to use, it may not work in the

Re: [Pharo-dev] About asClass and friend

Hi, > On Aug 26, 2016, at 9:10 AM, Esteban Lorenzano wrote: > >> >> On 26 Aug 2016, at 08:49, Luc Fabresse wrote: >> >> Hi, >> >> My point of view is: >> >> 1) in code/core, we should use (we already said that with Camille in the >> past ;-)):

Re: [Pharo-dev] About asClass and friend

2016-08-26 9:10 GMT+02:00 Esteban Lorenzano : > > On 26 Aug 2016, at 08:49, Luc Fabresse wrote: > > Hi, > > My point of view is: > > 1) in code/core, we should use (we already said that with Camille in the > past ;-)): > > self environmentAt: #Blah >

Re: [Pharo-dev] About asClass and friend

> On 26 Aug 2016, at 08:49, Luc Fabresse wrote: > > Hi, > > My point of view is: > > 1) in code/core, we should use (we already said that with Camille in the past > ;-)): > > self environmentAt: #Blah > > Object>>environmentAt: aSymbol > ^ self class

Re: [Pharo-dev] About better communication in the community

On Fri, 26 Aug 2016 14:27:24 +0800 Ben Coman wrote: > Definitely. And not necessarily that you *solve* an issues, but that > I found a benefit from "goal directed learning". That's a good point! > When I started using Pharo I learned a lot from: * trying to reproduce >

Re: [Pharo-dev] About asClass and friend

Hi, My point of view is: 1) in code/core, we should use (we already said that with Camille in the past ;-)): self environmentAt: #Blah Object>>environmentAt: aSymbol ^ self class environmentAt: aSymbol Object class>>environmentAt: aSymbol ... The idea is that we can then customize name

Re: [Pharo-dev] About better communication in the community

On Thu, 25 Aug 2016 23:06:51 +0200 Tudor Girba wrote: > It definitely does! We are all noobs in many parts in our system. Heh, I'm for the whole system. :-) > But, if you take your time and are willing to dig, the system is kind > enough to reveal itself to you :). That

Re: [Pharo-dev] About better communication in the community

On Thu, Aug 25, 2016 at 11:31 PM, Gour wrote: > On Thu, 25 Aug 2016 09:05:45 +0200 > stepharo wrote: > >> Yes but we cannot do much > > OK. I got it...do you believe it makes sense for a noob to create account > in case there are some low-hanging fruits to

Re: [Pharo-dev] About asClass and friend

Hi, > On Aug 26, 2016, at 6:37 AM, stepharo wrote: > > Thanks doru. > > I do not like when people think that we are complaining just because > something changes. > > It should change for the better and we all agree on that. Certainly. There are many points of view and

Re: [Pharo-dev] About asClass and friend

Thanks doru. I do not like when people think that we are complaining just because something changes. It should change for the better and we all agree on that. Stef Hi, There exists already a method for that: Symbol>>asClassInEnvironment: But, what if we introduce:

Re: [Pharo-dev] About better communication in the community

Hi Stef, 2016-08-25 3:48 GMT-03:00 stepharo : > Hi hernan > > Could you reply to my mail? Because what is important is how we can make > progres. > Ok, here it is :) > About GT I have some concerns too now I see also a lot of improvements. I > love GTInspector and we should

Re: [Pharo-dev] About asClass and friend

Hi, > On Aug 25, 2016, at 10:10 PM, stepharo wrote: > Hi, There exists already a method for that: Symbol>>asClassInEnvironment: But, what if we introduce: Symbol>>asClassFrom: anObject ^ self asClassInEnvironment: anObject

Re: [Pharo-dev] About better communication in the community

Hi, > On Aug 25, 2016, at 5:31 PM, Gour wrote: > > On Thu, 25 Aug 2016 09:05:45 +0200 > stepharo wrote: > >> Yes but we cannot do much > > OK. I got it...do you believe it makes sense for a noob to create acount > in case there are some low-hanging fruits

Re: [Pharo-dev] About asClass and friend

Ah, I am using that a lot to parametrize software. On one hand Pharo is breaking with the past, on the other one it sticks with it as much as possible? #MeConfused asHell. This has nothing to do with complying with the past. Do you think seriously that if we could replace self class env:

Re: [Pharo-dev] About asClass and friend

Hi, There exists already a method for that: Symbol>>asClassInEnvironment: But, what if we introduce: Symbol>>asClassFrom: anObject ^ self asClassInEnvironment: anObject class environment ? The problem is asClass unary. All the tools should be parametrized by an environment.

Re: [Pharo-dev] About asClass and friend

Yes this is what I was thinking too :) Hi 2016-08-25 8:52 GMT+02:00 Tudor Girba >: Furthermore, as #asClass is meant to be mainly used for convenience, not performance, I would also propose to make it lookup in thisContext and

Re: [Pharo-dev] About better communication in the community

On Thu, 25 Aug 2016 09:05:45 +0200 stepharo wrote: > Yes but we cannot do much OK. I got it...do you believe it makes sense for a noob to create acount in case there are some low-hanging fruits to pick? Sincerely, Gour -- From wherever the mind wanders due to its

Re: [Pharo-dev] About better communication in the community

Hi! Hola! I would like to help with some of this, so I sorted a bit the ideas in the previous emails to see if we can extract some concrete actions to apply. So I'll make a step back and put some titles to the topics of discussion: !Human/Social/Politics stuff 1) Policies - Deciding

Re: [Pharo-dev] About asClass and friend

Hi 2016-08-25 8:52 GMT+02:00 Tudor Girba : > Furthermore, as #asClass is meant to be mainly used for convenience, not > performance, I would also propose to make it lookup in thisContext and take > the environment from there. I know that his might sound like magic, but it >

Re: [Pharo-dev] About asClass and friend

Hi, > On Aug 25, 2016, at 9:52 AM, stepharo wrote: > > >> Hi, >> >> There exists already a method for that: >> Symbol>>asClassInEnvironment: >> >> But, what if we introduce: >> >> Symbol>>asClassFrom: anObject >> ^ self asClassInEnvironment: anObject class

Re: [Pharo-dev] About asClass and friend

Hi, There exists already a method for that: Symbol>>asClassInEnvironment: But, what if we introduce: Symbol>>asClassFrom: anObject ^ self asClassInEnvironment: anObject class environment ? The problem is asClass unary. All the tools should be parametrized by an

Re: [Pharo-dev] About asClass and friend

Le 25/8/16 à 08:34, Yuriy Tymchuk a écrit : Just my 2 cents: instead of #name asClass we have to use self class environment at: #name. Maybe instead of #at: we can have #classNamed:? Why not if it helps people :) Or something similar? Because 1) it’s not obvious that the method

Re: [Pharo-dev] About better communication in the community

Let us know because we do not I don't get why we don't have more discussions about end-developer tools : XML, i18n, GIS, simulation & expert systems, big data, reporting... Yes the idea is that we would like to try a process for Pharo and that such process can be used by other projects

Re: [Pharo-dev] About better communication in the community

Hello, Looking at bugs is really difficult. There are not enough people looking and fixing bugs. just a short note from a Pharo noob...it is, imho, very strange that one cannot even take a look at bugs *without* creating account at tracker. We know. Now the company offered us a

Re: [Pharo-dev] About asClass and friend

Le 25 août 2016 08:53, "Tudor Girba" a écrit : > > Hi, > > There exists already a method for that: > Symbol>>asClassInEnvironment: > > But, what if we introduce: > > Symbol>>asClassFrom: anObject > ^ self asClassInEnvironment: anObject class environment > > ?

Re: [Pharo-dev] About better communication in the community

Hi, Thanks Stef for the reply. I completely concur. @Hernán: About the issues with GT: please do get in touch. We have asked for it several times, and we are still here. If you have concrete issues, please raise them but focus on how to improve concretely. At the same time, also keep in mind

Re: [Pharo-dev] About asClass and friend

Hi, There exists already a method for that: Symbol>>asClassInEnvironment: But, what if we introduce: Symbol>>asClassFrom: anObject ^ self asClassInEnvironment: anObject class environment ? This would allow us to still script and be dynamic. Furthermore, as #asClass is meant

Re: [Pharo-dev] About better communication in the community

Hi hernan Could you reply to my mail? Because what is important is how we can make progres. About GT I have some concerns too now I see also a lot of improvements. I love GTInspector and we should remove EyeInspector. I want to have once brick is out another minimal environment not based

Re: [Pharo-dev] About asClass and friend

Just my 2 cents: instead of #name asClass we have to use self class environment at: #name. Maybe instead of #at: we can have #classNamed:? Or something similar? Because 1) it’s not obvious that the method will give you a class, what if in the future and environment can also have a

Re: [Pharo-dev] About asClass and friend

Ah, I am using that a lot to parametrize software. On one hand Pharo is breaking with the past, on the other one it sticks with it as much as possible? #MeConfused asHell. #SomeSymbol asClass looks very practical and cleaner that looking the class dictionary with at: #SomeSymbol Phil Phil Le

[Pharo-dev] About asClass and friend

Hi guys We got a meeting at ESUG with all the compiler guys and james from gemstone. Our goal is to have a full tool suite that can be parametrized by environments (so that we can compile code in other space, or compile other code inside pharo). I personnally started this effort one decade

Re: [Pharo-dev] About better communication in the community

Now I will try to be more positive. 2016-08-24 4:38 GMT-03:00 stepharo : > Hi Hernan > > First thanks for your email because we may disagree but we often agree. :) > so this is an email for me. > > Hi Stef, > > Good communication implies being clear when writing about sensitive

Re: [Pharo-dev] About better communication in the community

Hi, Esteban, Please don't take this personal, but we have differences :) 2016-08-24 5:06 GMT-03:00 Esteban Lorenzano : > Hi, > > I want to point just a couple of things: > > 1. You may feel hurt, but is my job to say no. If you think I’m doing a > bad job, is your right to

Re: [Pharo-dev] About Pharo 60

I cannot find the list, but there were some things we discussed during consortium call a month or so ago. Maybe Esteban can find it? I want for Christmas * Better Spec * Roadmap so we know where we are going, * with clean API, * so we can build really live UIs (where you can drag windows

Re: [Pharo-dev] About better communication in the community

> On 24 Aug 2016, at 10:07, Gour wrote: > > On Wed, 24 Aug 2016 09:38:20 +0200 > stepharo wrote: > > Hello, > >> Looking at bugs is really difficult. There are not enough people >> looking and fixing bugs. > > just a short note from a Pharo noob...it is,

Re: [Pharo-dev] About better communication in the community

On Wed, 24 Aug 2016 09:38:20 +0200 stepharo wrote: Hello, > Looking at bugs is really difficult. There are not enough people > looking and fixing bugs. just a short note from a Pharo noob...it is, imho, very strange that one cannot even take a look at bugs *without* creating

Re: [Pharo-dev] About better communication in the community

Hi, I want to point just a couple of things: 1. You may feel hurt, but is my job to say no. If you think I’m doing a bad job, is your right to discuss, but do not expect that what you consider a bad design decision would be shared by the board (and me as executor of board policies). 2.

Re: [Pharo-dev] About better communication in the community

Hi Hernan First thanks for your email because we may disagree but we often agree. :) so this is an email for me. Hi Stef, Good communication implies being clear when writing about sensitive topics, especially when communicating through virtual channels. I am not in Europe, so I cannot

Re: [Pharo-dev] About better communication in the community

Hi Stef, Good communication implies being clear when writing about sensitive topics, especially when communicating through virtual channels. I am not in Europe, so I cannot discuss these things with you face to face. Therefore is not clear to me (and others) what are your policies in many

Re: [Pharo-dev] About PythonDocTest for Pharo

I am sorry, but I want to said it: we have tests. Why tests are not for same purpose? (I would say they include it). As Tudor said: "they are way too disconnected from the code" And this needs to be solved. We already have nice feature in Nautilus: it shows "test icon" on covered

Re: [Pharo-dev] About PythonDocTest for Pharo

Ok this is your taste. My reality is different. Tests are far far away. I do not see them. They live in a different time zone. They are smart have a boring setup. I want documentation in front on my nose. No extra thinking no extra click Just right there. Stef Le 18/8/16 à 23:14, Denis

[Pharo-dev] About Pharo 60

Hi We have some ideas (because people are working on items) for the Pharo 6 roadmap and we will consolidate them soon and propose them to you. but I would like to know two kinds of points - what are the points you are working on and that would deserve more focus and help from the

[Pharo-dev] About better communication in the community

Hi guys the board got a good discussion at ESUG about how to improve and a lot of the discussion turned around improving communication. We got some ideas that we will propose soon but I would like to get *your* ideas. If you have idea about improving communication around pharo please tell

Re: [Pharo-dev] About PythonDocTest for Pharo

On Thu, Aug 18, 2016 at 11:28 PM, Denis Kudriashov wrote: > > 2016-08-18 13:32 GMT+02:00 stepharo : > >> withExtension: aString >> >> "Returns a new file reference with a different file extension" > > > Does this comment is really needed? > I only see

Re: [Pharo-dev] About PythonDocTest for Pharo

2016-08-18 13:32 GMT+02:00 stepharo : > withExtension: aString > > "Returns a new file reference with a different file extension" Does this comment is really needed? I only see extra word "different". And rest is same as method name. IMHO we should rename method to

Re: [Pharo-dev] About PythonDocTest for Pharo

Hi. 2016-08-18 9:34 GMT+02:00 stepharo : > withExtension: aString > > "Returns a new file reference with a different file extension" > > > value: '/tmp/file.log' asFileReference > > > ^ self withPath: (self path withExtension: aString) > > > So let me know what

Re: [Pharo-dev] About PythonDocTest for Pharo

As I already told you and the board, I will just leave if such a solution get pushed into Pharo. Hi, I like this problem very much. I think we are not leveraging the objects we have in the image. Tests can help, but they are way too disconnected from the code and they are not really useful

Re: [Pharo-dev] About PythonDocTest for Pharo

Hi, > On Aug 18, 2016, at 2:41 PM, stepharo wrote: > > Hi doru > > >> Hi, >> >> I like this problem very much. I think we are not leveraging the objects we >> have in the image. Tests can help, but they are way too disconnected from >> the code and they are not really

Re: [Pharo-dev] About PythonDocTest for Pharo

Hi doru Hi, I like this problem very much. I think we are not leveraging the objects we have in the image. Tests can help, but they are way too disconnected from the code and they are not really useful for detailed questions. I am also happy that you are considering the use of pragmas for

Re: [Pharo-dev] About PythonDocTest for Pharo

Hi, I like this problem very much. I think we are not leveraging the objects we have in the image. Tests can help, but they are way too disconnected from the code and they are not really useful for detailed questions. I am also happy that you are considering the use of pragmas for this

Re: [Pharo-dev] About PythonDocTest for Pharo

Tx serge - I think that we should agree on the pragma or way to express it. May be we can do the same as in Python and use a comment instead of a pragma. I prefer a pragma because we can query them easily. So any idea instead of withExtension: aString "Returns a new file

Re: [Pharo-dev] About PythonDocTest for Pharo

On Thu, Aug 18, 2016 at 9:34 AM, stepharo wrote: > Hi guys > > I'm fed up to get methods without comments and without little examples. In +1 ! We can setup a small group of people interested to build examples at ESUG. > FileSystem, I wrote most of the comments and I tried to

[Pharo-dev] About PythonDocTest for Pharo

Hi guys I'm fed up to get methods without comments and without little examples. In FileSystem, I wrote most of the comments and I tried to add an obvious example: basenameWithIndicator "Returns the basename with the indicator appended, i.e. /foo/gloops.taz basenameWithIndicator is

[Pharo-dev] About Integer readFrom: '12xx' ifFail: [ false ]

Hi I would really have an exact match ie Integer readFrom: '12xx' ifFail: [ false ] returning false and not 12. Any idea? May be I should use PetitParser. Stef

[Pharo-dev] about endless loop handling

Hi does it look like a taboo or we will never have decent endless loop handling? Stef

Re: [Pharo-dev] about ensureCreateFile

We were discussing it when I was in Lille. >From my side the conclusion was… do whatever you want with it, as long as there is a (new) method that raises an error when the parent does not exist. On Wed, May 25, 2016 at 8:40 AM, stepharo wrote: > I would like to move on on

[Pharo-dev] about ensureCreateFile

I would like to move on on this one: https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile I'm in favor of the change. But I'm all ears. Stef

Re: [Pharo-dev] About Smalltalk ui icons...

Le 22/5/16 à 20:44, Esteban Lorenzano a écrit : On 22 May 2016, at 17:51, stepharo wrote: loadConfigurationButton: aList aList act: [ :presenter | self onLoadFrom: presenter ] icon: Smalltalk ui icons configIcon entitled: 'Load configuration

Re: [Pharo-dev] About Smalltalk ui icons...

> On 22 May 2016, at 17:51, stepharo wrote: > > loadConfigurationButton: aList > >aList >act: [ :presenter | self onLoadFrom: presenter ] >icon: Smalltalk ui icons configIcon >entitled: 'Load configuration (do not install project)' > > > why

[Pharo-dev] About Smalltalk ui icons...

loadConfigurationButton: aList aList act: [ :presenter | self onLoadFrom: presenter ] icon: Smalltalk ui icons configIcon entitled: 'Load configuration (do not install project)' why we could not have something like loadConfigurationButton: aList aList

Re: [Pharo-dev] about spurious conflicts

The reason is that the merge does not find the “last common” package. There is an issue that solves this (adding temporarily the Pharo5 repo). Marcus > On 17 May 2016, at 22:08, stepharo wrote: > > Hi > > > while migrating some of the issues from 50 to 60, I

Re: [Pharo-dev] about spurious conflicts

Yes. It should be solved by 18251 2016-05-17 22:08 GMT+02:00 stepharo : > Hi > > > while migrating some of the issues from 50 to 60, I noticed that many of > the conflicts are > > not conflicts since

Re: [Pharo-dev] about spurious conflicts

> On 17 May 2016, at 22:08, stepharo wrote: > > Hi > > > while migrating some of the issues from 50 to 60, I noticed that many of the > conflicts are > > not conflicts since the code of both methods and the protocols are the same. > > Does anybody experienced the same? >

Re: [Pharo-dev] about spurious conflicts

2016-05-17 22:08 GMT+02:00 stepharo : > Hi > > > while migrating some of the issues from 50 to 60, I noticed that many of > the conflicts are > > not conflicts since the code of both methods and the protocols are the > same. > > Does anybody experienced the same? > > Here are

[Pharo-dev] about spurious conflicts

Hi while migrating some of the issues from 50 to 60, I noticed that many of the conflicts are not conflicts since the code of both methods and the protocols are the same. Does anybody experienced the same? Here are some examples and I'm puzzled.

<    1   2   3   4   5   6   7   8   9   10   >