- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [pharo-project/pharo-core] 6a5096: 40477

by Sven Van Caekenberghe

I see it as well from time to time in #40478 but not often and it does not seem to have any negative effect, I can just keep on working and there is no obvious slowdown. > On 06 Feb 2015, at 16:23, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 06 Feb 2015, at 09:07, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>>> >>>> Log Message: >>>> ----------- >>>> 40477 >>>> >>>> 14669 Delay refactoring (part 2a) - avoid UI locking up when timer event loop is stopped >>>> https://pharo.fogbugz.com/f/cases/14669 >>>> >>>> >>>> >>>> Thanks Max and Marcus for review and pushing this through. >>>> > > It seems to have some problem: > > WorldState>>#interCyclePause: failed > https://pharo.fogbugz.com/f/cases/14874 > > When e.g. in Nautilus searching for a class. > > Marcus

Feb. 6, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] 6a5096: 40477

by Marcus Denker

> On 06 Feb 2015, at 09:07, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >>> >>> Log Message: >>> ----------- >>> 40477 >>> >>> 14669 Delay refactoring (part 2a) - avoid UI locking up when timer event loop is stopped >>> https://pharo.fogbugz.com/f/cases/14669 >>> >>> >>> >>> Thanks Max and Marcus for review and pushing this through. >>> It seems to have some problem: WorldState>>#interCyclePause: failed https://pharo.fogbugz.com/f/cases/14874 When e.g. in Nautilus searching for a class. Marcus

Feb. 6, 2015

Re: [Pharo-dev] Parsing float difference between 2.0 and 3.0, was it on purpose?

by Marcus Denker

> On 06 Feb 2015, at 11:45, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > We have merged the parsers into one, because we had 3 parsers that didnât have any dedicated use-cases, juts were developed historical as at some point someone needed a bit more functionality, and then different parsers were used randomly on the system. Yes, it was quite hard to understand what was going on. And it is strange to have 3 different parsers for numbers... > As for the expression - yes we have to decide about it. If itâs only about being able to use exponent in float literals, one can use: âNumber readFrom: '2.5850009999999998e04ââ. If itâs about being similar to the other languages, we can also decide does it make sense to have a +2 literal. > If it makes no problems with backward compatibility, why not have both? > Uko > >> On 06 Feb 2015, at 09:04, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >>> On 06 Feb 2015, at 09:02, stepharo <stepharo(a)free.fr> wrote: >>> >>> >>> Le 5/2/15 10:40, Sven Van Caekenberghe a Ã©crit : >>>>> On 05 Feb 2015, at 10:36, Ben Coman <btc(a)openInWorld.com> wrote: >>>>> >>>>> I personally would prefer to be able to use exponents. No sure what the big picture is. >>>>> cheers -ben >>>> Of course exponents are still supported ;-) >>>> >>>> The discussion is about the + sign for positive exponents. I am not sure, but I think that traditional Smalltalk did not support this, but it was added to support common practice in other languages. Now it is apparently gone again, probably not on purpose. >>> >>> I do not know I think that marcus removed it to avoid to have two parsers in the image. >>> >> >> Maybe this was a mistakeâ¦ >> >> Marcus > >

Feb. 6, 2015

Re: [Pharo-dev] Switching to Pharo from Visualworks

by Marcus Denker

Yes, we need to improve that. Names are nice, but they make it harder to explore the system. > On 06 Feb 2015, at 12:43, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Markus Fritsche-4 wrote >> +1 to that one. > > Yes, I also find it difficult - much more so when I was new to the > community, but even still a bit now. Coral, Zinc, Seaside, Opal - may be > catchy, but when I'm browsing the system, I just want to see where the darn > WebClient is, not mine for minerals or go to the beach!! ;) j/k. But > seriously, it's one thing to have "sexy" names at the top level - Pharo, > Squeak, Ruby, Python; but inside the system, it definitely creates > confusion. It's perhaps extra difficult for us because some of these > projects have both an outside and inside identity. It's an interesting open > problem... maybe some metadata at the MetaC/package level could help? Like > some standard tags like #WebClient, #Compiler, etc to say logically what > role a project fills... > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Switching-to-Pharo-from-Visualworks-tp4803811p4804142… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Feb. 6, 2015

Re: [Pharo-dev] ||

by Ben Coman

On Fri, Feb 6, 2015 at 5:58 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Hi Eliot, > > maybe I'll frame the core question a bit differently, thanks to your > explanations. > > I see pragmas used mainly for two things: > > 1- expressing a link to some metadata used by low level tools: compiler, C > lang generator, etc... primitives for me are part of that. Kind of neat to > see that unified. > btw, I just used a pragma to solve this issue of getting correct debugger behaviour for halting and stepping over #halt statements [1]. There seem about a dozen methods that can cause a #halt spread between Object and Halt classes which should all behave similarly, so the options would seem * hardcode all these methods either into to check for in Halt>>signalerContext (or into a helper method called from #singalerContext) * have a convention for a certain protocol to hold these methods, which Halt>>signalerContext can look up (except currently the methods on Object are an extension protocol) * tag each such method with a pragma. This simplified the solution a lot. The search of the call stack just asked each method if it had the <debuggerCompleteToSender> pragma. > 2- categorizing things in a decoupled, package-extension compatible way. > > I still think there is something in the design that bother me. 1- and 2- > are convention-based, so as is most of Smalltalk anyway, so diregarding > another approach to 2- as convention-based is a bit dishonest: pragmas get > more authority because they look like they have been integrated in the > language definition compared to competing solutions. > > No, this is just because I start to wonder if methods shouldn't have a bit > more in that "define, add and manipulate" metadata idea, i.e. make it more > explicit and start to have tools which represent methods as more like > objects and not only text items (methods having metadata, additional slots > or instance variables, counters, statistics, ast, traces, break points, > etc...). And, in a way, a need to have two levels of execution: one which > happens at compile time (i.e. when one accept a method), one which happens > at runtime. > > For that, I think pragmas are a start, but they are not the complete > answer. And I think we should solve the package-extension compatible thing > in 2- to not have 2- (which is just for me a plain categorisation issue) > polluting the design by introducing additional/unrelated requirements. > > > > 2015-02-05 22:47 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> Hi Thierry, >> >> A block is far more difficult to deal with than a pragma. A pragma has a >> simple key, its selector, and simple access to its arameters, the >> arguments. A block is opaque. Essentially it can only be executable. >> Pragmas are both executable and function as annotations. >> > > Pragmas are executable, but in a context which is not visible at the place > they are written. > > >> >> >> >>> I strongly agree with your keep it in sync argument, still. Pragmas are >>> better than nothing. >>> >>>> >>>> >>>> There is no such need with pragmas; they are always in sync with the >>>> methods they describe because they are embedded in their methods. Instead >>>> we can use triggering to do useful things, adding a pane to open inspectors >>>> as soon as we define the method that describes the pane, adding or removing >>>> a menu entry, etc. >>>> >>> >>> Just a naming convention does just that perfectly fine, and with less >>> lines (except for extensions by external packages) and faster code in many >>> cases. >>> >> >> Yes, but there end up being lots of naming conventions and they are >> non-obvious. Whereas pragmas, because they are in-your-face in the methods >> in question, don't need conventions. They just need documenting ;-). >> > > They are still conventions which needs documentation. Pragmas are, in > allmost all uses, indirections (i.e. a tag meaning something to a far away > object), and the meaning associated to a pragma is, in every case, a > roll-your-own solution. And they are clearly "in your face" :) > > >> >> >> That's not necessarily true. Some pragmas do cause processing at compile >> time. For example, an FFI signature pragma can be checked at >> compile-time. But it's in keeping with smalltalk that type checking is not >> performed at compile time in most cases, isn't it? Why should one require >> that pragmas be semantically checked at compile time when normal SMalltalk >> code isn't? At least one knows that the message instance the pragma is >> compiled to is a valid object and *can* be performed. So pone does know at >> least that the pragma is executable. Obviously whether that ability to be >> executed only becomes potent with the right receiver. So any compiled >> pragma as the potential to be usefully evaluated. >> > > Ok, but its all fuzzy. > > It may be executed, but it may be not. > > It may send an error if incorrect, but it may fail silently. > > It may be executed at compile time, it may be executed sometime later > triggered by the compilation, or it may be executed at runtime, as if it > was normal code. And of course it may not be executed at all ... > > You see what I mean? > > >> >> And often it doesn't matter if the pragma reference a completely non >>> existent method or api, since it is probably never executed by anybody (and >>> if it is, it won't probably reify the error message properly as a >>> compilation error as it should, because it may be triggered miles away from >>> the system browser). >>> >> >> >> There is lots about Smalltalk that is non-obvious, about programming in >> general that is non-obvious. I don't see that as a specific criticism of >> pragmas. Once one knows the idiom it is easy to use; its wide-spread use >> is evidence of that. And hopefully this conversation will help make it >> more obvious :-). That it is limited is also not perhaps a useful >> criticism. The issue is whether it is adequate. I think it is. A literal >> message goes a long way. I'e not heard of complaints about limitations so >> far. Do you have specific examples where pragmas are inadequate? The >> tools /do/ support them. One can do senders and implementors in the >> browser and see the methods that include them, and the implementors of >> pragmas. browseAllSelect: will narrow down the search. There is an API >> for programmatic use (pragmasDo: et al). >> > > See [*][**] for the tools support. For me, pragmas, even in their > definition, have serious semantic issues. If they were strictly, as you > describe them, a metadata API access executed at compile time, then they > would be a lot stronger. > > Make them sent at compile-time on the method object, and that would > probably solve all the true arguments I have against them :) > > for example: <worldMenu> against <tagAndAnnounce: #worldMenu>; <tag: > #gtInspectorExtension> instead of <gtInspectorExtension>, etc... > > (<tagAndAnnounce:> would gain a bit of performance, as well). > > Thierry > > [*] Searching a bit for menu pragmas in a Pharo image seems to return a > bit of a mess. There is so many of them, all differents, and interestingly, > this does not return the code triggered (or using) them, which makes > discovery of what the pragma is used for (and its parameters) an > 'interesting' problem. > I think discoverability is an issue with pragmas. From Nautilus you can't "see" which methods contain which pragmas. I wonder if one solution for this would be for pramga methods to be grouped under a <virtual-protocol> in the third pane of Nautilus. [1] https://pharo.fogbugz.com/default.asp?12970 cheers -ben > > I suggest a task then: an illustrated sequence of how to search for the > code triggering world menu addition of a new command, for someone which is > new to Pharo ;) > > [**] even when used for categorisation, the API is prone to bugs, such as > having a method without pragma overriding a superclass method with pragma > because they have the same name. > >

Feb. 6, 2015

Re: [Pharo-dev] SmallInteger asByteArray for negative numbers

by Sven Van Caekenberghe

Alejandro, > On 06 Feb 2015, at 15:10, Alejandro Infante <alejandroinfante91(a)gmail.com> wrote: > > Hello, > I have just found that calling asByteArray for any negative small integer returns the same result that the positive small integer. Is it supposed to be like that or is it a bug? > > 1 asByteArray = -1 asByteArray. "true" > > (1 to: 100000) allSatisfy: [ :int | int asByteArray = int negated asByteArray ] âtrue" > > Cheers, > Alejandro (These kinds of questions should be asked on pharo-users(a)lists.pharo.org) You can only represent positive numbers as ByteArrays, because to represent negative numbers you have to decide how to do that. The most common solution is to use 2-complement. To do this you also need to decide on the number of bytes to use. Here is an example using 4 bytes: | integer size mask | integer := -123. size := 4. mask := (2 raisedTo: size * 8) - 1. (mask bitAnd: ((integer abs bitXor: mask) + 1)) asByteArrayOfSize: 4. => #[255 255 255 133] => FF FF FF 85 The reverse is: | integer size mask | integer := #[255 255 255 133] asInteger. size := 4. mask := (2 raisedTo: size * 8) - 1. (mask bitAnd: ((integer abs bitXor: mask) + 1)) negated This is for negative numbers. Positive numbers need not be 2-complemented. When decoding, integers < (2 raisedTo: (size * 8) - 1) are negative. HTH, Sven

Feb. 6, 2015

SmallInteger asByteArray for negative numbers

by Alejandro Infante

Hello, I have just found that calling asByteArray for any negative small integer returns the same result that the positive small integer. Is it supposed to be like that or is it a bug? 1 asByteArray = -1 asByteArray. "true" (1 to: 100000) allSatisfy: [ :int | int asByteArray = int negated asByteArray ] âtrue" Cheers, Alejandro

Feb. 6, 2015

Re: [Pharo-dev] Metacello + Filetree

by Sebastian Tleye

Hi Thierry, I still have the same problem, I managed to install and configure GitFiletree, I can add a remote git repository, load packages from it, etc. Also, I created a new stable version with the versioner. If I open the repository with Monticello I can see the history of the the packages, not only the last one. However, It's still throwing the same error, it cannot resolve the name of the package that it needs. (By the way, the development version can be still loaded correctly) Any Idea of what can it be? I am not an expert in Metacello, so maybe is a problem with the Configuration file (in the baseline I tried both, reference to the remote git repository and to the local gitfiletree repository) 2015-02-05 13:38 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > > > 2015-02-05 13:26 GMT+01:00 Sebastian Tleye <sebastian.tleye(a)gmail.com>: > >> Ok, great, I'll try GitFileTree, we are using the standard port. >> > > Please ask if you need any help. Criticism on the lack of documentation > and missing features accepted :) > > Thierry > > >> >> Thanks! >> >> 2015-02-05 12:53 GMT+01:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>: >> >>> Why not launching a kickstarter thing to have someone (you !) paid to >>> have a clean integration of git/pharo with documentation ? I guess people, >>> companies and associations like ESUG can give money for that. >>> >>> >>> Sent from my iPhone >>> >>> On 5 fÃ©vr. 2015, at 12:38, Thierry Goubier <thierry.goubier(a)gmail.com> >>> wrote: >>> >>> >>> >>> 2015-02-05 11:27 GMT+01:00 Sebastian Tleye <sebastian.tleye(a)gmail.com>: >>> >>>> Thanks Yuriy and Thierry, >>>> >>>> I see what I can do, I was using Bitbucket until some time ago but now >>>> we moved our project to a private git server! >>>> >>> >>> If you are on a private server, then GitFileTree will work (except if >>> the git server is on a non-standard port: I will add support for that in >>> the near future). >>> >>> Look for baselines and branches support to make your life (and your >>> configurations) simpler. >>> >>> As I said during PharoDays: we now have a good chunk of the necessary >>> infrastructure and we (the Pharo community) can develop additional support >>> if needed. Asking (funding) the consortium for that could be a real cool >>> way of contributing :) >>> >>> Thierry >>> >>> >>>> >>>> 2015-02-05 11:13 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: >>>> >>>>> Hi Sebastian, >>>>> >>>>> filetree only gives you access to the latest version of your packages, >>>>> and you can't access the history without access to the underlying version >>>>> control system you are using. >>>>> >>>>> This access for Metacello is available in two ways: via Metacello >>>>> github:// and bitbucket:// urls and tags or branches (but you need to be >>>>> using either github or bitbucket), or via GitFileTree if you are using git. >>>>> >>>>> Thierry >>>>> >>>>> 2015-02-05 11:03 GMT+01:00 Sebastian Tleye <sebastian.tleye(a)gmail.com> >>>>> : >>>>> >>>>>> Hi, >>>>>> >>>>>> I am using a filetree repository for my project, also I have created >>>>>> a first stable version using the versioner tool. >>>>>> Everything was working fine until I commited more changes, now when I >>>>>> want to install the stable version is throwing an error saying that cannot >>>>>> resolve the package that it needs, however if I load the development >>>>>> version it works perfectly. >>>>>> >>>>>> To clarify a little, >>>>>> >>>>>> The development version tries to load >>>>>> Phadeo-ImporterExporters-SebastianTleye.12 and it works perfectly. The >>>>>> stable version tries to load Phadeo-ImporterExporters-SebastianTleye.10 and >>>>>> it throws an error saying that it cannot be resolve. >>>>>> >>>>>> Any Idea of what is happening? >>>>>> I read that filetree and Metacello are compatibles so I don't know >>>>>> what's the problem >>>>>> >>>>> >>>>> Hi sebastian >>>>> >>>>> >>>>>> >>>>>> Thanks in advance >>>>>> >>>>>> SebastiÃ¡n Tleye >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> SebastiÃ¡n Tleye >>>> >>> >>> >> >> >> -- >> SebastiÃ¡n Tleye >> > > -- SebastiÃ¡n Tleye

Feb. 6, 2015

Re: [Pharo-dev] Switching to Pharo from Visualworks

by phil＠highoctane.be

Java has hadoop, spark, swing, spring, jaxb, jta, jdbc, atomikos, quartz, velocity, beanshell, ... iOS has a ton of weird names as well in frameworks. Knowing the lay of the land is part of taking part of any ecosystem. I actually like the names. As of VW you tell me what AppeX and SiouX are without knowing upfront. Phil Le 6 fÃ©vr. 2015 12:48, "Sean P. DeNigris" <sean(a)clipperadams.com> a Ã©crit : > Markus Fritsche-4 wrote > > +1 to that one. > > Yes, I also find it difficult - much more so when I was new to the > community, but even still a bit now. Coral, Zinc, Seaside, Opal - may be > catchy, but when I'm browsing the system, I just want to see where the darn > WebClient is, not mine for minerals or go to the beach!! ;) j/k. But > seriously, it's one thing to have "sexy" names at the top level - Pharo, > Squeak, Ruby, Python; but inside the system, it definitely creates > confusion. It's perhaps extra difficult for us because some of these > projects have both an outside and inside identity. It's an interesting open > problem... maybe some metadata at the MetaC/package level could help? Like > some standard tags like #WebClient, #Compiler, etc to say logically what > role a project fills... > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Switching-to-Pharo-from-Visualworks-tp4803811p4804142… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Feb. 6, 2015

Re: [Pharo-dev] ||

by Thierry Goubier

Hi Frank, so, which definition of pragmas I should follow? Declarative or executable? >From what you describe, I'm against it, they are just annotations (a way to convey programmer intention because the code itself is unable to do so). I introduce annotations in a programming language when I can't do otherwise because: the language is deficient in expressing the correct abstractions; or the compiler is too dumb to deduce properties on its own. Now, which one applies to Smalltalk pragmas? Thierry 2015-02-06 11:29 GMT+01:00 Frank Shearar <frank.shearar(a)gmail.com>: > > > Pragmas don't execute. They're _data_. There is no "calls unknown > sender" because the don't execute. > > Eliot's point is that pragmas _describe_, and then other systems act > on those descriptions. > > They're just like Java or C# attributes, or Python decorators. Only > they're better, because Java/C# attributes can do anything, whereas > pragmas merely describe. > > frank > > >

Feb. 6, 2015