[Pharo-dev] About removing class side initialization

Hi community I would like to get use your ideas. Here is the case Context: Class side initialize are not good. We fixed a bug with guille today (should do a PR) this bug was breaking some projects by changing the superclass of classes to Object. Radical! It was produced by

[Pharo-dev] About Undeclared

Hi, You might have seen that we have done some work related to Undeclared. I did some slides to explain how it worked / how it works now / what remaining problems are / next step. Undeclared.pdf Description: Adobe PDF document

[Pharo-dev] About thisContext in the Debugger

# Improving thisContext in the Debugger using First Class Variables Have you ever tried to inspect a thisContext variable in the debugger? Just interrupt Pharo by "CMD-.", the debugger appears with the main UI loop waiting on a Semaphore ""[delaySemaphore wait] in Delay>>wait". So if I now

[Pharo-dev] About Bag API

Hi I wonder why I cannot get values of a entry using at: | aBag | aBag := Bag new. aBag addAll: ‘aabbbacaccca’. aBag at: $a >>> 5 I have the impression that this is because Bag API never got the correct amount of love but may be I’m wrong. What is your opinion? S

[Pharo-dev] About Pull Request Reviews: Multiple Reviews are best!

Hi, If you see that a PR that you wanted to review already has a positive review, do not think “ah, nothing to be done for me”. Because imagine if the PR would be bad: you would add a comment how to improve in addition to the one already positive review. You should do the same even if you just

[Pharo-dev] About Image Size Pharo9->Pharo11

Pharo9: 65,8 MB Pharo10: 57,4 MB Pharo11: 56,5 MB The space saving come from three things: 1) Code cleanup Pharo9-Pharo10 = e.g. removal of support in Kernel and Compiler of old style blocks and bytecodes, to mention one smaller (in term of image size) but deep

[Pharo-dev] About ReToDoRule

I have never seen ReToDoRule to suggest a change that I wanted to do. I think it tries to detect if there is #at: send to the collection inside the block and suggests to use more high-level iterators. But the suggestions are odd and it seems to be too naive with just detecting the #at:

[Pharo-dev] About / and ZnUrl

Hi sven may be you know the answer :) 'http://www.pharo.org/figures/' asUrl / 'documentation/p.png' "http://www.pharo.org/figures/documentation/p.png” so far so good. 'http://www.pharo.org/figures/' asUrl / '/documentation/p.png' "http://www.pharo.org/figures//documentation/p.png; Why not

[Pharo-dev] about URL isAbsolute

Hi I’m a bit confused. When I use isAbsolute I get 'file:///toto.png' asUrl isAbsolute >>> false 'file://toto.png' asUrl isAbsolute >>> true Now I confused because as Unix / is absolute so file://toto.png would be relative. and /foo is absolute. Are URLs so different than files? Are

[Pharo-dev] About Pharo X nickname: "Cut the fat"

Hi pharoers just a little email to tell you that we are super happy because we are in the situation to remove old, unused or part in love for retirement from Pharo. And we are doing this at the level of the image but also the VM. So far we removed GT Glamour Alien

Re: [Pharo-dev] About strange email related to smalltalkhub read-only on squeak-dev

On Tue, Jun 2, 2020 at 6:18 AM Norbert Hartl wrote: > Hi Paul, > > thanks for the info but I won't read it. I try to focus on things that > matter. There are too many things that try to distract everyone from > producing something helpful. Law suits are IMHO not of that kind. > > I would rather

Re: [Pharo-dev] About strange email related to smalltalkhub read-only on squeak-dev

Hi Paul, thanks for the info but I won't read it. I try to focus on things that matter. There are too many things that try to distract everyone from producing something helpful. Law suits are IMHO not of that kind. I would rather put some money on the table for someone building proper FFI to

Re: [Pharo-dev] About strange email related to smalltalkhub read-only on squeak-dev

Hi Norbert, The EFF gives a nice overview of the US situation: https://www.eff.org/deeplinks/2019/08/us-export-controls-and-published-encryption-source-code-explained Although you are not a US citizen, and don't live here, so I don't know how it could affect you. In the link above the EFF

Re: [Pharo-dev] About strange email related to smalltalkhub read-only on squeak-dev

He’s on discord on squeak server. Maybe chatting with him in private could help resolve the misunderstanding. Cheers, Cedrick > Le 30 mai 2020 à 18:26, Norbert Hartl a écrit : > > Yes, let us coordinate what to respond. To me this doesn't even sound like > Ron. Usually he is a rather quite

Re: [Pharo-dev] About strange email related to smalltalkhub read-only on squeak-dev

Yes, let us coordinate what to respond. To me this doesn't even sound like Ron. Usually he is a rather quite and reasonable guy. Seems to be a lot of misunderstandings here (again). As I was the one copying the Cryptography package to github it concerns me a bit. I've been remembered now about

[Pharo-dev] About strange email related to smalltalkhub read-only on squeak-dev

Hi all This is the week-end and we worked super well yesterday during the sprint. Lot of good enhancements - Thanks a lot to all the participants. I not really happy to be forced to do it on a sunny saturday but I’m doing it to clarify points. Esteban sent me this text that was posted on

[Pharo-dev] about deprecation

Hi do you think that nbCall: fnSpec "You can override this method if you need to" self deprecated: 'use ffiCall: instead'. ^ (self ffiCalloutIn: thisContext sender) convention: self ffiCallingConvention; function: fnSpec library:

[Pharo-dev] About RBProgramNodeVisitor >> visitMethodNode: aMethodNode

While I can understand that RBProgramNodeVisitor >> visitMethodNode: aMethodNode does not return a value. - because visiting a program does not mean automatically to interpret it. RBProgramNodeVisitor >> visitMethodNode: aMethodNode self visitArgumentNodes: aMethodNode arguments.

Re: [Pharo-dev] about signal

While working on the booklet this week-end I was wondering (now I’m too dead to think and going to sleep) whether there is a semantics difference between resuming a suspended process using the message resume and “resuming a process” as a side effect of a wait signalled. S.

Re: [Pharo-dev] about signal

> > If processPreemptionYields false the output should be: > > ... > p2 > p1 > p2 > p1 > p2 > p1 > ... > > i.e. it is regular. What we're actually seeing is: > > ... > 'p1' > 'p2' > 'p1' > 'p2' > 'p2' > ... > > Which showing that p2 might get to signal multiple times before p1 > gets to

Re: [Pharo-dev] about signal

Hi Eliot, On Sun, 12 Jan 2020 at 18:16, Eliot Miranda wrote: > >> Hi Alastair, >> >> On Jan 12, 2020, at 12:34 AM, Alistair Grant wrote: >> >> I agree with Eliot that changing #processPreemptionYields to true by >> default would be an improvement in Pharo. It would make it easier to >> predict

Re: [Pharo-dev] about signal

Hi Alastair, >> On Jan 12, 2020, at 12:34 AM, Alistair Grant wrote: > On Thu, 9 Jan 2020 at 13:01, ducasse wrote: >> >> Hi >> >> I wanted to explain >> >> | semaphore p1 p2 | >> semaphore := Semaphore new. >> p1 := [ semaphore wait. >>'p1' crTrace ] fork. >> >> p2 := [semaphore

Re: [Pharo-dev] about signal

Hi Ben, On Sun, 12 Jan 2020 at 15:26, Ben Coman wrote: > > Now a new consideration for whether Pharo might change the default > processPreemptionYields to false > is ThreadedFFI. Presumably it will be common for a callback to be defined at > same priority as an in-image process. > I can't

Re: [Pharo-dev] about signal

On Sun, 12 Jan 2020 at 20:00, Sven Van Caekenberghe wrote: > Hi Alistair, > > > On 12 Jan 2020, at 09:33, Alistair Grant wrote: > > > > On Thu, 9 Jan 2020 at 13:01, ducasse wrote: > >> > >> Hi > >> > >> I wanted to explain > >> > >> | semaphore p1 p2 | > >> semaphore := Semaphore new. > >> p1

Re: [Pharo-dev] about signal

> > I also wasn't implying that we just go ahead and change it. But if it > is a possibility then I'll try changing it in my image and see how it > helps with tracking down inter-process interactions that we're > currently experiencing, and if it does introduce any showstopper > issues. Yes

Re: [Pharo-dev] about signal

Hi Stef, On Sun, 12 Jan 2020 at 11:28, ducasse wrote: > > Hi alistair > > > Hi > > I wanted to explain > > | semaphore p1 p2 | > semaphore := Semaphore new. > p1 := [ semaphore wait. >'p1' crTrace ] fork. > > p2 := [semaphore signal. > 'p2' crTrace ] fork. > > displays p2 and p1.

Re: [Pharo-dev] about signal

Hi Sven, In line below... Cheers, Alistair (on phone) On Sun., 12 Jan. 2020, 13:00 Sven Van Caekenberghe, wrote: > > Hi Alistair, > > > On 12 Jan 2020, at 09:33, Alistair Grant wrote: > > > > > > I agree with Eliot that changing #processPreemptionYields to true by > > default would be an

Re: [Pharo-dev] about signal

Hi Alistair, > On 12 Jan 2020, at 09:33, Alistair Grant wrote: > > On Thu, 9 Jan 2020 at 13:01, ducasse wrote: >> >> Hi >> >> I wanted to explain >> >> | semaphore p1 p2 | >> semaphore := Semaphore new. >> p1 := [ semaphore wait. >>'p1' crTrace ] fork. >> >> p2 := [semaphore

Re: [Pharo-dev] about signal

Hi Ben, > On 11 Jan 2020, at 10:50, Ben Coman wrote: > > > > On Sat, 11 Jan 2020 at 06:31, Sven Van Caekenberghe wrote: > Hi Ben, > > Great approach, though I would make one change to make your example > completely copy/paste runnable. > > Stef's original example: > > | trace semaphore

Re: [Pharo-dev] about signal

Hi alistair >> >> Hi >> >> I wanted to explain >> >> | semaphore p1 p2 | >> semaphore := Semaphore new. >> p1 := [ semaphore wait. >>'p1' crTrace ] fork. >> >> p2 := [semaphore signal. >> 'p2' crTrace ] fork. >> >> displays p2 and p1. >> but I would like explain clearly but

Re: [Pharo-dev] about signal

On Thu, 9 Jan 2020 at 13:01, ducasse wrote: > > Hi > > I wanted to explain > > | semaphore p1 p2 | > semaphore := Semaphore new. > p1 := [ semaphore wait. > 'p1' crTrace ] fork. > > p2 := [semaphore signal. > 'p2' crTrace ] fork. > > displays p2 and p1. > but I would like explain

Re: [Pharo-dev] about signal

Yes this was really fun for me to discover that in newProcess newProcess "Answer a Process running the code in the receiver. The process is not scheduled. IMPORTANT! Debug stepping this deep infrastructure may lock your Image If you are not sure what you are

Re: [Pharo-dev] about signal

On Sat, 11 Jan 2020 at 18:01, ducasse wrote: > > > On 11 Jan 2020, at 10:50, Ben Coman wrote: > > > > On Sat, 11 Jan 2020 at 06:31, Sven Van Caekenberghe wrote: > >> Hi Ben, >> >> Great approach, though I would make one change to make your example >> completely copy/paste runnable. >> >>

Re: [Pharo-dev] about signal

> On 11 Jan 2020, at 10:50, Ben Coman wrote: > > > > On Sat, 11 Jan 2020 at 06:31, Sven Van Caekenberghe > wrote: > Hi Ben, > > Great approach, though I would make one change to make your example > completely copy/paste runnable. > > Stef's original example: > > |

Re: [Pharo-dev] about signal

On Sat, 11 Jan 2020 at 06:31, Sven Van Caekenberghe wrote: > Hi Ben, > > Great approach, though I would make one change to make your example > completely copy/paste runnable. > > Stef's original example: > > | trace semaphore p1 p2 | > > semaphore := Semaphore new. > > trace := [ :message | >

Re: [Pharo-dev] about signal

>>> >>> :) >> :) >> >> Sometimes I do not know if my humour is strange or not :) > > It is! And you are the only one having that kind of humor ;) Not sure that we are safe : https://www.thefarside.com Just arrived last month and it is super great

Re: [Pharo-dev] about signal

> Am 10.01.2020 um 22:32 schrieb ducasse : > >  >> ducasse wrote >>> It was so simple that I preferred to do it myself so like that I will look >>> like a great Pharo contributor. >> >> :) > :) > > Sometimes I do not know if my humour is strange or not :) It is! And you are the only one

Re: [Pharo-dev] about signal

Thanks Sven I started to use the suggestions of Ben. And I’m thinking that I could show my version then step back and explain that indeed there is another process (the UI one). I will digest your example and produce a new version of the booklet and people can give feedback. S. > On 10

Re: [Pharo-dev] about signal

Hi Ben, Great approach, though I would make one change to make your example completely copy/paste runnable. Stef's original example: | trace semaphore p1 p2 | semaphore := Semaphore new. trace := [ :message | ('[{1}] {2}' format: { Processor activeProcess priority. message }) crLog

Re: [Pharo-dev] about signal

Hi Nicolas, Sure the implementation description is super important, and did not say that. All I said is that it is an implementation description and not a high level one. I just checked the descriptions starting page 257 of the Smalltalk-80 The Language book, as well as VisualWorks's 1.0

Re: [Pharo-dev] about signal

On Fri, Jan 10, 2020 at 2:01 PM Eliot Miranda wrote: > Hi Steph, > > > On Jan 10, 2020, at 12:42 PM, ducasse wrote: > > Yes this is why in my chapter on Exception I show the VM code while some > people told me that it was not interesting. > And this is why in the current chapter on semaphore I

Re: [Pharo-dev] about signal

Thanks ben, this is a nice idea to illustrate what is happening I will use it. Thanks for the VM code :). I like it too. I will add a note also mentioning that indeed there is a process to execute the snippets that the reader will write and execute :). Stef PS: what makes me laugh a bit

Re: [Pharo-dev] about signal

Hi Steph, On Jan 10, 2020, at 12:42 PM, ducasse wrote: Yes this is why in my chapter on Exception I show the VM code while some people told me that it was not interesting. And this is why in the current chapter on semaphore I have a section on the implementation. Now it does not mean that the

Re: [Pharo-dev] about signal

> ducasse wrote >> It was so simple that I preferred to do it myself so like that I will look >> like a great Pharo contributor. > > :) :) Sometimes I do not know if my humour is strange or not :) But strange humour is better than no humour :) Stef PS: I read too many gary larson comics to

Re: [Pharo-dev] about signal

ducasse wrote > It was so simple that I preferred to do it myself so like that I will look > like a great Pharo contributor. :) - Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] about signal

Yes this is why in my chapter on Exception I show the VM code while some people told me that it was not interesting. And this is why in the current chapter on semaphore I have a section on the implementation. Now it does not mean that the we cannot have a higher view too :). > On 10 Jan

Re: [Pharo-dev] about signal

Done. https://github.com/pharo-project/pharo/issues/5466 It was so simple that I preferred to do it myself so like that I will look like a great Pharo contributor. > On 10 Jan 2020, at 06:30, Danil Osipchuk wrote: > > Maybe to add this into the class comment, this is the most

Re: [Pharo-dev] about signal

For greater visibility and comprehension, it might be useful to early in the manual define a utility method... Object>>crTracePriority self crTrace: '[', Processor activePriority printString, ']', self printString On Fri, 10 Jan 2020 at 13:13, Eliot Miranda wrote: > > > On Thu, Jan 9,

Re: [Pharo-dev] about signal

For example, whether a Semaphore would queue waiting process by order of registration (thru a linked list for example) or by order of priority (thru a Heap for example), would completely change its behavior. So isn't that kind of implementation detail SUPER important, especially when hidden in VM?

Re: [Pharo-dev] about signal

I didn't claim expertise on the subject (although I use semaphores extensively), nor its simplicity, nor that the implementation description should be the only guide on its usage (hence 'to add..., how it works' wording) Said that, to me it is the case, when a clear description of what is going on

Re: [Pharo-dev] about signal

Actually, it is just a, albeit concise, description of how Semaphores are implemented. It does not help much in understanding them, in learning how they can/should be used, for what purposes and how code behaves. Understanding of Process, priorities and Scheduling are also needed for a more

Re: [Pharo-dev] about signal

Maybe to add this into the class comment, this is the most concise and clear description of how it works i've ever seen пт, 10 янв. 2020 г., 8:13 Eliot Miranda : > > > On Thu, Jan 9, 2020 at 5:03 AM ducasse wrote: > >> Hi >> >> I wanted to explain >> >> | semaphore p1 p2 | >> semaphore :=

Re: [Pharo-dev] about signal

On Thu, Jan 9, 2020 at 5:03 AM ducasse wrote: > Hi > > I wanted to explain > > | semaphore p1 p2 | > semaphore := Semaphore new. > p1 := [ semaphore wait. > 'p1' crTrace ] fork. > > p2 := [semaphore signal. > 'p2' crTrace ] fork. > > displays p2 and p1. > but I would like

Re: [Pharo-dev] about signal

here is what I’m writing in the book. Let us image that we have the following two processes and one semaphore. [[[ | semaphore p1 p2 | semaphore := Semaphore new. p1 := [ semaphore wait. 'p1' crTrace ] fork. p2 := [ semaphore signal. 'p2' crTrace

[Pharo-dev] about signal

Hi I wanted to explain | semaphore p1 p2 | semaphore := Semaphore new. p1 := [ semaphore wait. 'p1' crTrace ] fork. p2 := [semaphore signal. 'p2' crTrace ] fork. displays p2 and p1. but I would like explain clearly but it depends on the semantics of signal.

[Pharo-dev] About package deprecation

--- Begin Message --- Hi all, As everyone knows, the BlueInk and GTRecorder packages have been removed from Pharo8.0 quite rapidly https://github.com/pharo-project/pharo/issues/5217. And it breaks the loading of other projects on Pharo8.0, like Roassal2. Some claims that those packages

[Pharo-dev] About dashed lines in Athens

Hi to all I was playing with Athens and I found and error that you can reproduce with the next script in Pharo8x64 macOs ```Smalltalk AthensSurfaceExamples openViewOn: [ :can | can pathTransform restoreAfter: [ can pathTransform translateX: 30 Y: 30. can pathTransform rotateByDegrees: 35. can

[Pharo-dev] about common command

Hi I played a bit to turn smart suggestion actions into commander2 commands. It works :). Now with CM2 we do not have to have a class per command. We can create an instance. Now I was wondering what we prefer - using classes + we can dispatch later (for example suggestions dispatch on

Re: [Pharo-dev] about threeWayCompareTo:

Thanks Nicolas. We should check because cyril told me that the primitive was implemented but not published in the primitive table. We will have a look. S. > On 16 Sep 2019, at 19:42, Nicolas Cellier > wrote: > > This comparison was part of MiscPrimitivePlugin. > MiscPrimitivePlugin is a

Re: [Pharo-dev] about threeWayCompareTo:

This comparison was part of MiscPrimitivePlugin. MiscPrimitivePlugin is a false good idea: Smalltalk fallback code = VMMaker (slang) source Unfortunately, this is an illusion because unlike the C source inclusions in ST/X we don't have dynamic slang compilation! The consequence is that source

Re: [Pharo-dev] about threeWayCompareTo:

I haven't followed nor maintained the SortFunctions library, but it relied heavily on the response of that method, by means of the "spaceship operator" ( #<=>), I think that Sven later changed such operator to "threeWayCompareTo:". I don't know whether the primitive is available now, it wasn't

Re: [Pharo-dev] about threeWayCompareTo:

This was WIP, don't know if it stalled... Le lun. 16 sept. 2019 à 08:52, ducasse a écrit : > I see > > threeWayCompareTo: aString > "Do a three-way comparison between the receiver and anotherObject, > returning > -1 if self < anotherObject > 0 if self = anotherObject >

[Pharo-dev] about threeWayCompareTo:

I see threeWayCompareTo: aString "Do a three-way comparison between the receiver and anotherObject, returning -1 if self < anotherObject 0 if self = anotherObject 1 if self > anotherObject This assumes a total order in accordance with the mathematical law

Re: [Pharo-dev] About tweets

>>> non-technical topics on my blog as well (which I do not plan). >>> >>> >>> Basically we have four options: >>> a) we only link to the official twitter account >>> (https://twitter.com/pharoproject) and blog >>> (https://pharowe

Re: [Pharo-dev] About tweets

k to the official twitter account >> (https://twitter.com/pharoproject) and blog >> (https://pharoweekly.wordpress.com/) >> b) extend the list with personal twitter accounts as mentioned in issue >> #4491 and blogs like mentioned in #4490 >> c) Link and rely on e

Re: [Pharo-dev] About tweets

> c) Link and rely on external aggregators > d) Setup an own aggregator on sources we trust > > Maybe as a valid solution an official "disclaimer" could help - that opinions > shared on these PROMOTED sources are not controlled by > us and do not necessarily refl

Re: [Pharo-dev] About tweets

o from the community page. Thanks T. > Gesendet: Donnerstag, 05. September 2019 um 08:03 Uhr > Von: "ducasse" > An: "Pharo Development List" > Cc: "The Pharo Project" > Betreff: [Pharo-dev] About tweets > > Hi guys > > I encourage everybody

Re: [Pharo-dev] About tweets

Ok, there seems to be some agreeable sense. Dealing with accounts of people tends to collect opinions and things not related to pharo. We are not interested in these. There are hashtags and mentions for things related to a topic. But a few (!) want to have more control. So using the

Re: [Pharo-dev] About tweets

Yes, I closed that issue. This is not going to happen, sorry :) Esteban > On 5 Sep 2019, at 08:03, ducasse wrote: > > Hi guys > > I encourage everybody to read this issue until the last conversation. > https://github.com/pharo-project/pharo/issues/4491 > > I have problem to promote

[Pharo-dev] About tweets

Hi guys I encourage everybody to read this issue until the last conversation. https://github.com/pharo-project/pharo/issues/4491 I have problem to promote an aggregator that can contain tweets containing #abortionismurder inside.! And I have even more problem that this is in a

Re: [Pharo-dev] About resurrecting the RE package and plugin

I have a related solution that's coded at my level of Pharo skillz (aka hacked). I used LibC and Perl to code a matches: method. It seems to work well, but Perl has to be in the path. The prototype with tests is at https://github.com/fuhrmanator/Keshi self assert: ('a.*?com' asKSRegex matches:

Re: [Pharo-dev] About

tx! > On 11 Apr 2019, at 14:42, Sophie Kaleba wrote: > > HI, > We actually talked about this very primitive with Cyril not that long ago. > I'll have a look at it with him this week so it can be used ! > > Sophie > > Le mer. 10 avr. 2019 à 14:10, ducasse > a

Re: [Pharo-dev] About

HI, We actually talked about this very primitive with Cyril not that long ago. I'll have a look at it with him this week so it can be used ! Sophie Le mer. 10 avr. 2019 à 14:10, ducasse a écrit : > Thanks I did not know it was on a mailing-list. > > > On 10 Apr 2019, at 14:02, Nicolas Cellier

Re: [Pharo-dev] About

Thanks I did not know it was on a mailing-list. > On 10 Apr 2019, at 14:02, Nicolas Cellier > wrote: > > Hi Stephane, > If you google 'vm-dev VMMaker.oscog-sk.2367' > and click one of the first hits > https://marc.info/?l=squeak-vm-dev=152413936110744=2 >

Re: [Pharo-dev] About

> On 10 Apr 2019, at 14:01, Cyril Ferlicot wrote: > > On Wed, Apr 10, 2019 at 1:52 PM ducasse wrote: >> >> Nicolas >> >> I tried to find the new primitive and I did not find it here >> >>

Re: [Pharo-dev] About

Hi Stephane, If you google 'vm-dev VMMaker.oscog-sk.2367' and click one of the first hits https://marc.info/?l=squeak-vm-dev=152413936110744=2 you'll see the changes from Sophie: The new InterpreterPrimitives>>primitiveCompareWith should be linked to primitive 158. (and only for ByteString

Re: [Pharo-dev] About

On Wed, Apr 10, 2019 at 1:52 PM ducasse wrote: > > Nicolas > > I tried to find the new primitive and I did not find it here > > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/src/plugins/MiscPrimitivePlugin/MiscPrimitivePlugin.c > > I found the old one. > Did I look in the wrong

Re: [Pharo-dev] About

Nicolas I tried to find the new primitive and I did not find it here https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/src/plugins/MiscPrimitivePlugin/MiscPrimitivePlugin.c I found the old one. Did I look in the wrong place? Stef > On 10 Apr 2019, at 13:46, ducasse wrote: > >

Re: [Pharo-dev] About

Thanks nicolas so we can use them then. > On 10 Apr 2019, at 11:59, Nicolas Cellier > wrote: > > VMMaker.oscog-sk.2367 > Author: sk > Time: 19 April 2018, 12:02:35.661622 pm > UUID: 0c2401e3-1450-4f73-8e81-958f50171595 > Ancestors: VMMaker.oscog- nice.2366 > > ** new primitive to compare

Re: [Pharo-dev] About

VMMaker.oscog-sk.2367 Author: sk Time: 19 April 2018, 12:02:35.661622 pm UUID: 0c2401e3-1450-4f73-8e81-958f50171595 Ancestors: VMMaker.oscog- nice.2366 ** new primitive to compare strings (slang + JIT) answers negative smi, 0 or positive smi (instead of 1, 2 or 3 in the MiscPlugin) * Slang

Re: [Pharo-dev] About

> On 10 Apr 2019, at 11:42, Cyril Ferlicot wrote: > > On Wed, Apr 10, 2019 at 10:42 AM Stéphane Ducasse > mailto:stephane.duca...@inria.fr>> wrote: >> >> Hi >> >> I recall that clement told me that returning 1,2 or 3 instead of negative, >> zero, positive was slow. >> And I wonder if the

Re: [Pharo-dev] About

On Wed, Apr 10, 2019 at 10:42 AM Stéphane Ducasse wrote: > > Hi > > I recall that clement told me that returning 1,2 or 3 instead of negative, > zero, positive was slow. > And I wonder if the primitive got change to the logic clement proposed? > > Could we not introduce another primitive and use

[Pharo-dev] About

Hi I recall that clement told me that returning 1,2 or 3 instead of negative, zero, positive was slow. And I wonder if the primitive got change to the logic clement proposed? Could we not introduce another primitive and use it from the image? compare: string1 with: string2 collated: order

Re: [Pharo-dev] About a better filedialog

> On 21 Mar 2019, at 10:14, Hilaire wrote: > > Peter's FileDialog looks so much better than FileList :) :) Stef > > Le 20/03/2019 à 20:09, ducasse a écrit : >> I was thinking the FileList. >> Now I will look at the FileDialogWindow :) >> >> Stef > > -- > Dr. Geo > http://drgeo.eu > >

Re: [Pharo-dev] About a better filedialog

Peter's FileDialog looks so much better than FileList :) Le 20/03/2019 à 20:09, ducasse a écrit : > I was thinking the FileList. > Now I will look at the FileDialogWindow :) > > Stef -- Dr. Geo http://drgeo.eu

Re: [Pharo-dev] About a better filedialog

Hi, While a good FileDialog may have a preview… I think the best thing is that you can take the component and reuse it, adding the behaviour you want. At least, that would be the purpose of Spec, isn’t? So… you could not wait until someone add a preview and you could add the preview you like

Re: [Pharo-dev] About a better filedialog

I checked and they are not related. And we can keep for now the DileDialogWindow. Stef > On 20 Mar 2019, at 20:09, ducasse wrote: > > > >> On 20 Mar 2019, at 19:29, Hilaire wrote: >> >> Ah, may be we are not talking about the same tool. I am talking about >> the FileDialogWindow, I think

Re: [Pharo-dev] About a better filedialog

> On 20 Mar 2019, at 19:29, Hilaire wrote: > > Ah, may be we are not talking about the same tool. I am talking about > the FileDialogWindow, I think part of the Gary's Polymorph. And you > about FileList according to your screenshot. > > Is Peter's FileDialog intend is to replace FileList?

Re: [Pharo-dev] About a better filedialog

Ah, may be we are not talking about the same tool. I am talking about the FileDialogWindow, I think part of the Gary's Polymorph. And you about FileList according to your screenshot. Is Peter's FileDialog intend is to replace FileList? Or FileDialogWindow? Hilaire Le 20/03/2019 à 19:13,

Re: [Pharo-dev] About a better filedialog

> On 19 Mar 2019, at 20:35, Hilaire wrote: > > For DrGeo, when loading a sketch from an arbitrary location, I use the > preview feature of the polymorph File Dialog. I don't see it in this > simple replacement of File Dialog. Can you send a snippet so that I can see what it means because I

Re: [Pharo-dev] About a better filedialog

Something as simple as in the current filedialog will be far than enough: an option to toggle a preview display. It is then the responsibility of the user to code the preview view. I am afraid an inspector view will look too hackish for a user like a teacher or a kid. Hilaire Le 19/03/2019 à

Re: [Pharo-dev] About a better filedialog

Preview is indeed not supported. My original idea was to show a regular GTInspector view on the file, but I never got around to implementing it. On Tue, Mar 19, 2019 at 8:36 PM Hilaire wrote: > For DrGeo, when loading a sketch from an arbitrary location, I use the > preview feature of the

Re: [Pharo-dev] About a better filedialog

For DrGeo, when loading a sketch from an arbitrary location,  I use the preview feature of the polymorph File Dialog. I don't see it in this simple replacement of File Dialog. Hilaire Le 18/03/2019 à 20:31, ducasse a écrit : > what do you think? > > https://github.com/Ducasse/file-dialog

Re: [Pharo-dev] About a better filedialog

gt;> Let me know what you think. >> >> Stef >> >>> On 18 Mar 2019, at 21:20, Alexandre Bergel >> <mailto:alexandre.ber...@me.com>> wrote: >>> >>> >>> From: Alexandre Bergel >> <mailto:alexandre.ber...@me.com

Re: [Pharo-dev] About a better filedialog

; >> On Mon, Mar 18, 2019 at 9:23 PM ducasse wrote: >> >>> Alex >>> >>> Have a look at the one I propose and play with it. >>> Let me know what you think. >>> >>> Stef >>> >>> On 18 Mar 2019, at 21:20, Alexandre Berge

Re: [Pharo-dev] About a better filedialog

tef >> >> On 18 Mar 2019, at 21:20, Alexandre Bergel >> wrote: >> >> >> *From: *Alexandre Bergel >> *Subject: **Re: [Pharo-dev] About a better filedialog* >> *Date: *18 March 2019 at 21:20:35 CET >> *To: *Pharo Development List >> >> &g

Re: [Pharo-dev] About a better filedialog

21:20, Alexandre Bergel > <mailto:alexandre.ber...@me.com>> wrote: >> >> >> From: Alexandre Bergel > <mailto:alexandre.ber...@me.com>> >> Subject: Re: [Pharo-dev] About a better filedialog >> Date: 18 March 2019 at 21:20:35 CET >> To: Pharo De

Re: [Pharo-dev] About a better filedialog

at you think. > > Stef > > On 18 Mar 2019, at 21:20, Alexandre Bergel > wrote: > > > *From: *Alexandre Bergel > *Subject: **Re: [Pharo-dev] About a better filedialog* > *Date: *18 March 2019 at 21:20:35 CET > *To: *Pharo Development List > > > I do not have tim

Re: [Pharo-dev] About a better filedialog

Alex Have a look at the one I propose and play with it. Let me know what you think. Stef > On 18 Mar 2019, at 21:20, Alexandre Bergel wrote: > > > From: Alexandre Bergel > Subject: Re: [Pharo-dev] About a better filedialog > Date: 18 March 2019 at 21:20:35 CET > To: P

Re: [Pharo-dev] About a better filedialog

--- Begin Message --- I do not have time to personally work on this. But yes, having a better file dialog would be fantastic Alexandre > On Mar 18, 2019, at 4:31 PM, ducasse wrote: > > Hi guys > > I did a pass (ported to P7, tonel, some little fixes) on the file-dialog > developed by Peter

  1   2   3   4   5   6   7   8   9   10   >