Re: [Pharo-dev] Parsing float difference between 2.0 and 3.0, was it on purpose?
Le 5/2/15 10:40, Sven Van Caekenberghe a écrit : On 05 Feb 2015, at 10:36, Ben Coman b...@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. On Thu, Feb 5, 2015 at 12:27 AM, Mariano Martinez Peck marianop...@gmail.com wrote: Hi guys, In Pharo 2.0, the expression Number readFrom: '2.58500098e+04' would answer 25850.01 , but in Pharo 3.0 it answers: 2.58500097 which is a kind of WTF to me. Checking the differences it seems in Pharo 2.0 ExtendedNumberParser (used from Number readFrom: ) implemented: allowPlusSign ^true However, in Pharo 3.0 it seems subclasses of NumberParser have been merged directly in NumberParser class (and so Number readFrom: uses this class now). But.. (and this is the difference), NumberParser implements: allowPlusSign ^false So I wonder...was this on purpose or a side effect? Why would we want to reject using + as part of the exponential notion?? So in my case now I must do an override to: NumberParser allowPlusSignInExponent ^ true Thoughts? -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-dev] Switching to Pharo from Visualworks
Hi steven I have a largish project (Siren) that I have developed in ST80/VisualWorks (since 1984) and ported to Squeak in the past. I'm allows looking for a cleaner free ST80 implementation to host the project. Good. I would love to see Siren in Pharo and I'm ready to help. Looking at Pharo, it appears to me to be suffering the same bloat issues as Squeak. Well if you say that it is that you are just looking at the tip of iceberg. This is not for fun that we are massively working on cleaning dependencies and removing wrong code or rewriting it. In the coming months we will work on putting in place our bootstrapping kernel. There are no Smalltalk able to do that right now. Bootstrapping means a lot in term of quality. But we have some work to get there and we are busy with our real work (publishing papers). BTW: When I come to friend place I do not start to piss on the door, usually I try to understand the tradition of the place and get more information before judging. I will take your remarks with a bit of salt and reply to you as a welcome message. :) I have a few questions: Why don't you all use a 6-paned browser (called the package browser in Squeak) and control the introduction of top-level meta-categories? Because you have tags and you can filter packages. Now the new browser is not the final answer. You could imagine also that your browser is empty at first and only contain your projects and that you can add incrementally the class and packages of interest. Now we did not have the cycle to experiment with that and hope other people will try. We should do another pass on cleaning simplifying nautilus. Thetop-level (packages or meta-catgories) should be a list of 20 or fewer topics such as Magnitudes, Collections, Graphics, Text, Compiler, Tools, etc. and each of these should have 20 or fewer categories within it It is just a view on the world. Why would I be interested in Magnitudes. I have no idea what it is and I do not care. But we are working on it. We should restart. First we needed to throw away the old Browser code. The default browser is not the end of the road just the current result of our learning. We are working on packages meta data and projects but it takes time. Iported the package browser to Squeak and reorganized their system once, but people continued to add top-level categories to make finding their code easier. I tried to add the facility to the Pharo browser a year or so ago, and gave up because I couldn't figure how out how to subclass and refine the existing browser framework (and the fact that it seems to be under construction). We should do a pass on it. Now to me the sith pane is not the right way to me. Did you see that there are tags inside packages. BTW Pharo packages are real objects not string comparisons and it took us time to make this changes. Why do you still use the (terrible, IMHO) Squeak graphics and UI packages (Morphic, Balloon, etc)? It appears that new mostly-redundant systems are still being added to replace these, right? Give me 5 Million $ and you will see. Pharo will not look like it is. We are not Alan Kay to raise money. Can't someone reimplement the VisualWorks Wrapper UI framework (or something like it) on top of OpenGL contexts as in VW? It's help up pretty well after over 25 years. (David Leibs and I toasted it just last December in Australia.) We have Spec which is a Wrapper frmeworks but there are plenty of space for improvements. And we are WORKING on OUR FREE time on making Athens (vector graphics API supporting different back ends) fully rendering the system. In fact nicolai hess is pushing this massive effort. How many engineers were working for free in VisualWorks? How many people were paid? So far we got three engineers working in Pharo for 3 years. How does a newbie learn what all the new packages are for? Glamour, Ring, AsmJit, Zinc, etc. are neat names, but if they're not part of higher-level packages it makes navigating the system (and even figuring out what they're for) pretty difficult. We know. We started to add meta data to package and based on that we want to display the package description. But days here are only 24 hours. Are there any benchmarks of the current VMs compared to VisualWorks? The last time I used Squeak (a few years ago) it was still pretty slow. I have a real-time event scheduler in Siren that I use to schedule MIDI, so I can run drum roll tests to see how the VM performs. check Cog VM. Now there is Spur a new memory manager coming along and it will speed things. Read the blog of clement bera or eliot miranda. Then clement is working on Sista an image level inliner and optimizer and it will bring really new perspective. How does Pharo handle user primitives or foreign function calls? Is anyone maintaining the old SWIG implementation of Smalltalk? I used it quite a bit to have Smalltalk code create and manage C++ signal processing graphs in
Re: [Pharo-dev] Parsing float difference between 2.0 and 3.0, was it on purpose?
On 06 Feb 2015, at 09:02, stepharo steph...@free.fr wrote: Le 5/2/15 10:40, Sven Van Caekenberghe a écrit : On 05 Feb 2015, at 10:36, Ben Coman b...@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
Re: [Pharo-dev] Switching to Pharo from Visualworks
Le 5/2/15 11:57, Markus Fritsche a écrit : On Thu, 5 Feb 2015 11:45:53 +0100 Serge Stinckwich serge.stinckw...@gmail.com wrote: - Glamour : https://ci.inria.fr/pharo-contribution/view/Books/job/DeepIntoPharo/lastSuccessfulBuild/artifact/tmp/Glamour.pdf - Zinc : https://github.com/SquareBracketAssociates/EnterprisePharo/tree/master/Zinc-HTTP Thanks, but that was meant more general. If I fire up the Pharo Launcher and go to the configuration browser, I see 25 offerings on the first page, of which roughly 50% (12) give me an idea what they're about. The other 13 - I really have no clue and need to google them ;-) if the project configurationOf defines a description the flybyhelp shows its description when you load it. Now this is only until recently that ConfigurationOf were kept in the image so we will revisit the description to make sure that they are defined. If I'm having a problem with the browser implementation, AltBrowser might be a thing to look at. If SuperGemMiley (which might also implement an alternative browser) is something I should look at, I will only find out if I google name pharo and write down whatever comes up on github, smalltalkhub, jenkins... :-) We are **working** on a package catalog web site. Best regards, Markus
Re: [Pharo-dev] [pharo-project/pharo-core] 6a5096: 40477
On 05 Feb 2015, at 21:34, Max Leske maxle...@gmail.com wrote: On 05 Feb 2015, at 17:46, Ben Coman b...@openinworld.com mailto:b...@openinworld.com wrote: On Thu, Feb 5, 2015 at 11:12 PM, GitHub nore...@github.com mailto:nore...@github.com 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 https://pharo.fogbugz.com/f/cases/14669 Thanks Max and Marcus for review and pushing this through. Next step is Issue 14353 Delay refactoring (Part 2) - change from milliseconds to microseconds and I started to review rebasing this onto the latest build. Now left over from Part 1 (https://pharo.fogbugz.com/default.asp?14261 https://pharo.fogbugz.com/default.asp?14261) is lots of conditional code wrap of the form... self newCodeEnabled ifTrue: [ my new code ] ifFalse: [ the old code ] However this conditional code wrap clutters things making it harder to review changes going forward. So I was wondering it was preferable for me to clean that out first, before pushing 14353 for review. For Part 1 it served a few purposes... (1) It was required to make an instantaneous transition to the new architecture. However this no longer required since integration of Issue 14669 now allows the DelayScheduler to be stopped to change code without locking the system. (2) It provided an emergency fallback to disable the new architecture, since this was deep-diving into critical infrastructure. However Part 1 was integrated in November, so is that long enough for the code to have proved itself? I would say so, yes. (3) It allowed easy switching back and forth for benchmarking. Maybe still useful, but I don't think this is enough on its own to keep the newCodeEnabled conditional code wraps. Benchmarking can still be done on separate build before and after integration of subsequent changes. You can recompile on the fly if you really need to use the same image. Please advise how you'd like me to proceed. cheers -ben I’d go ahead and remove the conditionals and the old code. The release of Pharo 4 is planned for April I think, so even if something goes wrong, there’s still time to fix it. Removing the clutter will also make it easier to review your changes; and it will make writing code for you easier. Yes! If you can choose between “cleaning up” and “continue to work”, choose cleaning up. It will be the right choice in most cases… Marcus
Re: [Pharo-dev] SmallInteger asByteArray for negative numbers
On 06 Feb 2015, at 18:03, Ben Coman b...@openinworld.com wrote: On Fri, Feb 6, 2015 at 10:48 PM, Sven Van Caekenberghe s...@stfx.eu wrote: Alejandro, On 06 Feb 2015, at 15:10, Alejandro Infante alejandroinfant...@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: 10) allSatisfy: [ :int | int asByteArray = int negated asByteArray ] “true Cheers, Alejandro (These kinds of questions should be asked on pharo-us...@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 I was going to complain about expecting such niceties as a built in 2s-complement rather than program it myself (I am a bit rusty on such matters), but when I look what should I find? (-123 asTwosComplement: 16r) asByteArray. = #[255 255 255 133] cheers -ben That is nice indeed, I didn't that existed. Very handy. I don't like that there are no tests ;-)
Re: [Pharo-dev] Howto create a new configuration?
2015-02-06 1:40 GMT+01:00 Juraj Kubelka juraj.kube...@gmail.com: Well, then I cannot see packages that are not included in the version 2.7. Can you mention some? I will try to make a new version. I want to include the latest versions of Athens-Cairo: Athens-Cairo-NicolaiHess.82 and Athens-Text: Athens-Text-NicolaiHess.16 The other packages hasn't change since version 2.7 nicolai Juraj 5. 2. 2015 v 20:07, Nicolai Hess nicolaih...@web.de: 2015-02-05 23:06 GMT+01:00 Juraj Kubelka juraj.kube...@gmail.com: I have downloaded the latest Pharo 4 and it looks like Esteban Lorenzano did the job. There is a new 2.7 version. No, the version 2.7 is not new, I have some changes that came after that version. Cheers, Juraj 5. 2. 2015 v 18:28, Nicolai Hess nicolaih...@web.de: 2015-02-05 21:56 GMT+01:00 Juraj Kubelka juraj.kube...@gmail.com: I am just guessing: try to click on “development” item on the left side. - Information: Nothing to save Already tried :) Cheers, Juraj 5. 2. 2015 v 17:13, Nicolai Hess nicolaih...@web.de: Hello, I fixed some issues for Athens and upload the changes to the repository. Now, I want to use Versionner to create a new configuration. What I tried: Open a fresh image Open the Athens repository and load the new changesets - There are some merge conflicts. Why? There shouldn't be any conflicts. How do you do this? After merging the changes I open Versionner. I thought I have to make a new Release but the button Release Version is disabled. What did I miss? nicolai
Re: [Pharo-dev] Parsing float difference between 2.0 and 3.0, was it on purpose?
2015-02-06 16:18 GMT+01:00 Marcus Denker marcus.den...@inria.fr: On 06 Feb 2015, at 11:45, Yuriy Tymchuk yuriy.tymc...@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... No it's not strange. 2 different parsers respond to 2 different syntax and expectations. To me it's quite clear: - The SmalltalkNumberParser was there to parse a Smalltalk syntax (badly named SqNumberParser in the ages...) It should do this thru Number readSmalltalkSyntaxFrom: '1.0e4' - The ExtendedNumberParser was there to parse an extended syntax (the one most apps handling data from oustide world will wish to parse). It should do this thru Number readFrom: '1.0e+4' - The FortranNumberParser was just an unused experiment. Its sole goal was to expose an example of how a GenericNumberParser could be subclassed. Such class has a better place in a cook-book than in the image, so Bye bye. Date readFrom: '2015/02/06' readStream does not have to follow a Smalltalk syntax, so why Number readFrom: '1.0e+4' readStream would have to? As Yuriy underlined, we might extend the Smalltalk syntax to embrasse some of external world patterns, why not, but it's limited and is going to be a problem with formats like '.2' or '2.e0'. Whether the extended parser should be in the core image or not is a valid question. We all agree that Pharo is all but finished and need to be constantly cleaned up. The challenge is how can Pharo change but remain application-writer-friendly? So two different things are: - the value of the feature: is it worth maintaining it or not? If yes, should it be maintained outside the core, or inside by the Pharo-team? I agree that removing incomplete features is a valid strategy when the team is too small - the quality of implementation And there are two ways of cleaning: - clean a dirty implementation, but keep the feature (eventually with a different API) - remove the feature, based on a value/cost analysis Here, I feel like it's the dictatorship which sounds questionnable. Were the feature understood? There were unit tests and class comments, so pretending to not understand is not really an excuse. Were the value of the features discussed? Maybe in a small core team... From outside, we don't really know. Were an externalisation of the feature and transfer of maintenance to a 3rd party discussed? I'm not aware of. I'm sure it would have been a better decision. So from my POV, such decision process remains to improve. It sounds too light and arbitrary. In some cases, I have the impression that the volunty of cleaning is too much dogmatic. I agree that too much pragmatism won't lead to a clean image any time soon... I agree that Pharo team has a licence to change things and should decide, otherwise let's all stick to Squeak ;) But a bit of democratie, argumentation and COORDINATION does not hurt. Then how can user support be improved? - Is it possible to write release notes helping the transition? (were is located the add-on package that enables compatibility, who maintains it, is there a new and better API, etc...) - Could some automated AST-based refactorings be prepared and applied auto-magically? It's not necessarily the sole business of Pharo-team, user community could help writing such notes. Nicolas 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.58500098e04’”. 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.den...@inria.fr wrote: On 06 Feb 2015, at 09:02, stepharo steph...@free.fr wrote: Le 5/2/15 10:40, Sven Van Caekenberghe a écrit : On 05 Feb 2015, at 10:36, Ben Coman b...@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
[Pharo-dev] CFP - IWST 2015
[Please accept our apologies if you receive multiple copies of this call] [Please send to interested colleagues / mailing-lists] CALL FOR PAPERS IWST15 — International Workshop on Smalltalk Technologies Brescia, Italy; July 15, 2015 http://www.esug.org/wiki/pier/Conferences/2015/International-Workshop-IWST_15 --- Goals and scopes --- The goals of the workshop is to create a forum around advances or experience in Smalltalk and to trigger discussions and exchanges of ideas. The topics of your paper can be on all aspect of Smalltalk, theoretical as well as practical. Participants are invited to submit research articles or industrial papers. This year we want to open two different tracks: one research track and one industrial track with less scientific constraints. We expect papers of three kinds: Short position papers describing emerging ideas Long research papers with deeper description of experiments and of research results. Industrial papers with presentation of real and innovative Smalltalk applications; this kind of paper should enlighten why Smalltalk is really appropriate for your application. We will not enforce any length restriction. Important Dates Submission deadline: April 10th, 2015 Notification deadline: May 20th, 2015 Workshop : July 15th, 2015 All accepted papers will be published in ACM DL (To be confirmed) --- Topics --- We welcome contributions on all aspects, theoretical as well as practical, of Smalltalk related topics such as: -Aspect-oriented programming, -Design patterns, -Experience reports, -Frameworks, -Implementation, new dialects or languages implemented in Smalltalk, -Interaction with other languages, -Meta-programming and Meta-modeling, -Tools --- Best Paper Award --- To encourage the submission of high-quality papers, the IWST organizing committee is very proud to announce a Best Paper Award for this edition of IWST. We thank the Lam Research Corporation for its financial contribution which makes it possible for prizes for the three best papers: 1000 USD for first place, 600 USD for second place and 400 USD for third place. The ranking will be decided by the program committee during the review process. The awards will be given during the ESUG conference social event. The Best Paper Award will take place only with a minimum of six submissions. Notice also that to be illegible, a paper must be presented at the workshop by one of the author and that the presenting author must be registered at the ESUG conference. --- Publication --- Both submissions and final papers must be prepared using the ACM SIGPLAN 10 point format. Templates for Word and LaTeX are available at http://www.acm.org/sigs/sigplan/authorInformation.htm. This site also contains links to useful informations on how to write effective submissions. --- Submission --- All submissions must be sent via easychair: https://easychair.org/conferences/?conf=iwst2015 --- Program chairs --- Anne Etien (Université de Lille 1, France) Jannik Laval (Ecole des Mines de Douai, France) -- ~~Jannik Laval~~ École des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://www.approchealpes.info http://car.mines-douai.fr/
Re: [Pharo-dev] ||
Le 5/2/15 22:47, Eliot Miranda a écrit : Yes, but that's because of historical accident and the difficulty of keeping docs up to date. Perhaps Pharo By Example can fix this? Yes we should. My writing todo is a bit huge :)
Re: [Pharo-dev] Howto create a new configuration?
I have changed two methods of the configuration: -=-=- stable: spec symbolicVersion: #stable spec for: #'pharo2.x' version: '2.1'. after some modification in NB made it incompatible with 3.0 spec for: #'pharo3.x' version: '2.3'. spec for: #'pharo4.x' version: '2.7’. “== added, maybe instead of pharo4.x could be common -=-=- development: spec symbolicVersion: #'development' spec for: #'common' version: '2.3-baseline’. “== it is likely not necessary -=-=- I have changed it, because I think there should be two lines in Versioner: one with development label, second with stable label. Then everything works. Let me know if it helps. Juraj 6. 2. 2015 v 17:28, Nicolai Hess nicolaih...@web.de: 2015-02-06 1:40 GMT+01:00 Juraj Kubelka juraj.kube...@gmail.com mailto:juraj.kube...@gmail.com: Well, then I cannot see packages that are not included in the version 2.7. Can you mention some? I will try to make a new version. I want to include the latest versions of Athens-Cairo: Athens-Cairo-NicolaiHess.82 and Athens-Text: Athens-Text-NicolaiHess.16 The other packages hasn't change since version 2.7 nicolai Juraj 5. 2. 2015 v 20:07, Nicolai Hess nicolaih...@web.de mailto:nicolaih...@web.de: 2015-02-05 23:06 GMT+01:00 Juraj Kubelka juraj.kube...@gmail.com mailto:juraj.kube...@gmail.com: I have downloaded the latest Pharo 4 and it looks like Esteban Lorenzano did the job. There is a new 2.7 version. No, the version 2.7 is not new, I have some changes that came after that version. Cheers, Juraj 5. 2. 2015 v 18:28, Nicolai Hess nicolaih...@web.de mailto:nicolaih...@web.de: 2015-02-05 21:56 GMT+01:00 Juraj Kubelka juraj.kube...@gmail.com mailto:juraj.kube...@gmail.com: I am just guessing: try to click on “development” item on the left side. - Information: Nothing to save Already tried :) Cheers, Juraj 5. 2. 2015 v 17:13, Nicolai Hess nicolaih...@web.de mailto:nicolaih...@web.de: Hello, I fixed some issues for Athens and upload the changes to the repository. Now, I want to use Versionner to create a new configuration. What I tried: Open a fresh image Open the Athens repository and load the new changesets - There are some merge conflicts. Why? There shouldn't be any conflicts. How do you do this? After merging the changes I open Versionner. I thought I have to make a new Release but the button Release Version is disabled. What did I miss? nicolai
Re: [Pharo-dev] ||
Really interesting discussion. I like pragmas but this is interesting to see them challenged. 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 ;-). Thierry I'm skeptical that multiple protocol will save the problem because you will rely on coding conventions. And pragma is a clever tagging. Stef
Re: [Pharo-dev] ||
Le 6/2/15 19:15, Thierry Goubier a écrit : The good old finder has a pragmas search mode which allows for a bit of discoverability (pragma users), but it doesn't link to the code exploiting the pragmas. Do you know if we have something specific on SmartSuggestions for pragmas? point taken. Indeed it would would be nice. Stef
Re: [Pharo-dev] Switching to Pharo from Visualworks
Am 06.02.15 12:43, schrieb Sean P. DeNigris: 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 +1 The names of these frameworks are nice as long as they are outside the image. Inside the image the focus should be on functionality (at least as long as the frameworks are unique). For somebody new to Pharo this is quite irritating. Andreas 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.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] ||
I would love to see an editor, which works on the AST directly - aka it maps the source code to AST nodes, and just updates the smallest possible subtree at each keystroke. Implementing such editor has it's challenges ofc, like typing a single character can invalidate the whole code, but the editor should keep the AST somehow in that case too. Me too and I want pretty print as you type :) A student will probably want to start that adventure so we will have fun. Another way to see it: How would the original Smalltalk be designed if they would have had 4GB RAM in 1978? What fascinates me still is that Smalltalk used the existing resources (even building their own machines) to an extreme, while today we are obsessed to find reasons why we can not do anything that makes the system slower or use more memory than yesterday. And that even with resources growing every year… This is why we e.g. now have a meta object describing every instance variable in Pharo. I am sure there are people who will see these ~7000 objects as pure waste… while I would say that we have already *now* the resources to be even more radical. I think this is a different thing. Improvements are always welcome, as long as they don't step on your toes. About Slots: I don't see their advantages yet (other than bitfields, but those are so rare in Smalltalk that I implement them causes no trouble. And they are just an optimization over using multiple fields.). Levente Marcus
Re: [Pharo-dev] Switching to Pharo from Visualworks
Le 6/2/15 16:31, Sven Van Caekenberghe a écrit : Yes, but that is not really provided as a #catalog* method, is it ? There is #catalogDescription, but that is some lines of text. There should be something like #catalogLabel for a sjort one-line title style label. if configuration would be filled up we could take advantage of them. The flybyhelp when hovering over a package is displaying the description of project (when there is one) since two years. Stef On 06 Feb 2015, at 16:26, Esteban Lorenzano esteba...@gmail.com wrote: there should be both: a name and a category Seaside - Web framework Zinc - HTTP server etc. Esteban On 06 Feb 2015, at 16:16, Marcus Denker marcus.den...@inria.fr wrote: 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 s...@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.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] development workflow for GTools (GToolkitCore)
Would it be possible/desirable to have a system such that:
* bug fixes for external packages can be still be directly applied and
tested in the Pharo-integrated branch
* the CI workflow generates an updated ConfigurationOf{external
package} that it pushes back to the external package repository?
Yes this is the process I had in mind but this is not that simple
because the configuration of the external package may also have changed
and a merge should be done in the external package.
Its a great idea to separate out Configurations to devolve
responsibility for sub-packages, but it adds some friction to bug fixing.
Yes I always thought about it.
It seems we will have a single branch combining both feature
development and bug-fixing, but it would be nicer to have two branches.
---
On another track, I wonder if it would be useful if a package which is
part of a Configuration is made dirty, the Configuration itself could
also be marked dirty?
cheers -ben
On Fri, Feb 6, 2015 at 4:36 AM, Nicolai Hess nicolaih...@web.de
mailto:nicolaih...@web.de wrote:
14850 https://pharo.fogbugz.com/default.asp?14850 Integrate
GTools #development
From this version onwards the development version should be
integrated.
Is this a good idea? Does the #development version always include
*all* the latest
changes, because after Andrei opened
14866 https://pharo.fogbugz.com/default.asp?14866 Integrate
GTools (which got integrated in 40475)
I uploaded some changes for issue
14608 https://pharo.fogbugz.com/default.asp?14608
ClassTest#testClassRespectsPolymorphismWithTrait failing due to
Spotter methods
I set the status to Fix Review needed,
but my changes are integrated in 40475 too!
I am not satisfied with the way external packages are handled.
1. if there is not one slice/changeset per issue, it is even less
likely someone will
review the changes.
2. you don't know who works when on a issue. They are solved in a
bulk.
3. a new configuration might not only includes bugfixes but new
features as well.
4. often we have unbound globals / undeclared references or other
test failures.
Can we use the build server for those external projects (like
GToolkitCore, Athens, TxText),
and that if a project makes a new configuration, it uses the same
issue validator for loading and testing that configuration?
nicolai
Re: [Pharo-dev] SmallInteger asByteArray for negative numbers
I would have like to know when I wrote the chapter in deepinto pharo about 2 complement... Stef (These kinds of questions should be asked on pharo-us...@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 I was going to complain about expecting such niceties as a built in 2s-complement rather than program it myself (I am a bit rusty on such matters), but when I look what should I find? (-123 asTwosComplement: 16r) asByteArray. = #[255 255 255 133] cheers -ben That is nice indeed, I didn't that existed. Very handy. I don't like that there are no tests ;-)
Re: [Pharo-dev] [Slots] Invisible Slots
I want relationships for certain modeling purposes
What I like is that we should arrive to get a collection of useful slots
with optimal implementation instead all of us reinventing the wheel.
Stef
Le 6/2/15 18:15, Marcus Denker a écrit :
On 06 Feb 2015, at 11:50, Marcus Denker marcus.den...@inria.fr wrote:
Next: When building classes with Slots, the class builder need to call back on
the slot and hand the class to each. Then the slot
can reflectively change the class, e.g. the PropertySlot will check if there is
already a hidden property base slot and if not, add it
reflectively).
This is now done:
https://pharo.fogbugz.com/f/cases/14876/Add-call-back-in-ClassBuilder-to-call-slots-when-building-a-class
For playing with this, in 479:
InstanceVariableSlot subclass: #AccessorSlot
slots: { }
classVariables: { }
category: ‘Package'
two methods, #installingIn and #removingFrom:, which are called by the class
builder:
installingIn: aClass
| reader writer |
reader := String streamContents: [ :str |
str
nextPutAll: self name;
cr;tab;
nextPutAll: ' ^';
nextPutAll: self name.
].
writer := String streamContents: [ :str |
str
nextPutAll: self name;
nextPutAll: ': anObject';
cr;tab;
nextPutAll: self name;
nextPutAll: ':= anObject.'.
].
aClass compile: reader classified: 'accessing'.
aClass compile: writer classified: 'accessing’.
removingFrom: aClass
aClass removeSelector: self name.
aClass removeSelector: self name asMutator.
Now we can make a class and see how the accessors are automatically added (and
removed when the slot is removed):
Object subclass: #TT
slots: { # = AccessorSlot }
classVariables: { }
category: ‘Package'
NOTE: this is an example of what can be done with Slots. It is *not* an example
of what *should* be done with Slots.
(this we only will know after using them for a while).
Marcus
Re: [Pharo-dev] ||
2015-02-06 18:29 GMT+01:00 Eliot Miranda eliot.mira...@gmail.com: On Fri, Feb 6, 2015 at 1:58 AM, Thierry Goubier thierry.goub...@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. There's a third use that is, I think, the most powerful. Maybe you see this as the same as 1, but I don't. The method is a component to be included in some larger structure, e.g. it is an action method on a menu, or it is an implementation of a pane in an inspector. The pragma is the message to be sent to the object that manipulates that larger structure to add the method to it. This is how menu pragmas work in VW. There is an object called a MenuBuilder. To add a method to a menu (and which menu is described by the pragma) the menu builder sets the method as its current method and then performs the pragma. The parameters in the pragma allow the MenuBuilder to add the method in the right way to the menu. But the execution of the pragma is what actually adds the mehtod to the menu. So its a combination of specification and execution. You mean as a sort of lightweight command object? Pharo uses that for its world menu, Nautilus for its menus, and probably in a few other places. I also like to define command objects for that purpose, because it gives you more flexibility and power while keeping all concerns together: complex commands depending on the context of their creator, having both a menu entry and a shortcut, controlling whether they are enabled or not... I also like command objects because they usually force a bit of a dedicated category for them, and may avoid a spread of pragmas tagged methods left and right in the package. I have no problem with your criticism of pragmas used for categorisation. Method categories are already there and sometimes much more appropriate than pragmas. For example, in the SPur bootstrap the methods to be added or modified in Spur are included in categories of SpurBootstrapPrototypes and its subclasses. If there were pragmas in these methods then the pragmas would be copied into Spur, which is not at all what I want. Instead I copy across the methods in the relevant categories. But this not a complete solution feels to me an unfair criticism. Pragmas are what they are and they can do a lot. But no part of the system does everything. A system is composed of components. I agree with that, and the fact that well, maybe, someone will come along with something better :) Thierry
Re: [Pharo-dev] ||
2015-02-06 18:41 GMT+01:00 Eliot Miranda eliot.mira...@gmail.com: Or are you talking about the lack of class pragmas? This is a point. But classes already have an executable hook they can use for system modification, their class-side initialize and obsolete methods. That's been used for a long time to address system modification needs on installing and removing classes. So form that perspective there's less of a need to class pragmas. Instead we're focussing on more specialised class definition facilities such as slots, which are intrinsic to classes, i.e. define the class itself, rather than pragmas, which are extrinsic to methods in that they define how methods interact in the system outside themselves. Maybe what you are saying here holds what I am longing for. Something as simple and as well defined as aClass classinitialize (simple, solve-it-all mechanism for all initialization needs in a class, full smalltalk based so easily discoverable) or now the class slots, but applied to methods and their metadata. Pragmas are a first step towards that, but I have a feeling we could do it better (and it seems, with some of the changes coming such as traces, in-image optimisations, breakpoints, etc... it may be usefull or overgrow the pragmas). Thierry
Re: [Pharo-dev] ||
On Fri, Feb 6, 2015 at 2:12 PM, Thierry Goubier thierry.goub...@gmail.com wrote: 2015-02-06 18:29 GMT+01:00 Eliot Miranda eliot.mira...@gmail.com: On Fri, Feb 6, 2015 at 1:58 AM, Thierry Goubier thierry.goub...@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. There's a third use that is, I think, the most powerful. Maybe you see this as the same as 1, but I don't. The method is a component to be included in some larger structure, e.g. it is an action method on a menu, or it is an implementation of a pane in an inspector. The pragma is the message to be sent to the object that manipulates that larger structure to add the method to it. This is how menu pragmas work in VW. There is an object called a MenuBuilder. To add a method to a menu (and which menu is described by the pragma) the menu builder sets the method as its current method and then performs the pragma. The parameters in the pragma allow the MenuBuilder to add the method in the right way to the menu. But the execution of the pragma is what actually adds the mehtod to the menu. So its a combination of specification and execution. You mean as a sort of lightweight command object? Pharo uses that for its world menu, Nautilus for its menus, and probably in a few other places. I also like to define command objects for that purpose, because it gives you more flexibility and power while keeping all concerns together: complex commands depending on the context of their creator, having both a menu entry and a shortcut, controlling whether they are enabled or not... I also like command objects because they usually force a bit of a dedicated category for them, and may avoid a spread of pragmas tagged methods left and right in the package. Yes, a Message instance is a command object, pragmas are Message instances, therefore pragmas are command objects. So using pragmas to associate menu action methods with their menus embeds the relevant command objects in the menu action methods. I have no problem with your criticism of pragmas used for categorisation. Method categories are already there and sometimes much more appropriate than pragmas. For example, in the SPur bootstrap the methods to be added or modified in Spur are included in categories of SpurBootstrapPrototypes and its subclasses. If there were pragmas in these methods then the pragmas would be copied into Spur, which is not at all what I want. Instead I copy across the methods in the relevant categories. But this not a complete solution feels to me an unfair criticism. Pragmas are what they are and they can do a lot. But no part of the system does everything. A system is composed of components. I agree with that, and the fact that well, maybe, someone will come along with something better :) Thierry -- best, Eliot
Re: [Pharo-dev] Switching to Pharo from Visualworks
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.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] [pharo-project/pharo-core] 6a5096: 40477
+1 STef Le 5/2/15 21:34, Max Leske a écrit : On 05 Feb 2015, at 17:46, Ben Coman b...@openinworld.com mailto:b...@openinworld.com wrote: On Thu, Feb 5, 2015 at 11:12 PM, GitHub nore...@github.com mailto:nore...@github.com 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. Next step is Issue 14353 Delay refactoring (Part 2) - change from milliseconds to microseconds and I started to review rebasing this onto the latest build. Now left over from Part 1 (https://pharo.fogbugz.com/default.asp?14261) is lots of conditional code wrap of the form... self newCodeEnabled ifTrue: [ my new code ] ifFalse: [ the old code ] However this conditional code wrap clutters things making it harder to review changes going forward. So I was wondering it was preferable for me to clean that out first, before pushing 14353 for review. For Part 1 it served a few purposes... (1) It was required to make an instantaneous transition to the new architecture. However this no longer required since integration of Issue 14669 now allows the DelayScheduler to be stopped to change code without locking the system. (2) It provided an emergency fallback to disable the new architecture, since this was deep-diving into critical infrastructure. However Part 1 was integrated in November, so is that long enough for the code to have proved itself? I would say so, yes. (3) It allowed easy switching back and forth for benchmarking. Maybe still useful, but I don't think this is enough on its own to keep the newCodeEnabled conditional code wraps. Benchmarking can still be done on separate build before and after integration of subsequent changes. You can recompile on the fly if you really need to use the same image. Please advise how you'd like me to proceed. cheers -ben I’d go ahead and remove the conditionals and the old code. The release of Pharo 4 is planned for April I think, so even if something goes wrong, there’s still time to fix it. Removing the clutter will also make it easier to review your changes; and it will make writing code for you easier. Pharo 4 is still in development (unless I missed something), and development means unstable environment. People who use Pharo 4 are aware of that. That’s my two cents anyway. Keep up the great work! Cheers, Max
Re: [Pharo-dev] Switching to Pharo from Visualworks
On 06.02.2015 09:33, stepharo wrote: In the coming months we will work on putting in place our bootstrapping kernel. There are no Smalltalk able to do that right now. GNU Smalltalk does just that, if it doesn't find an image, it will be bootstrapped by using the shipped .st fileouts. A bit of cheating is involved, a compiler initialization is implemented on the VM side. So I would say there are no Smalltalk that are able to do that right now the way we want to do it :-P (Pissing at the door contest, to refer to another unquoted metaphor :-D)
Re: [Pharo-dev] ||
On 5 February 2015 at 21:20, Thierry Goubier thierry.goub...@gmail.com wrote: 2015-02-05 21:28 GMT+01:00 Eliot Miranda eliot.mira...@gmail.com: On Thu, Feb 5, 2015 at 11:34 AM, Thierry Goubier thierry.goub...@gmail.com wrote: 2015-02-05 18:51 GMT+01:00 Eliot Miranda eliot.mira...@gmail.com: On Thu, Feb 5, 2015 at 2:31 AM, Thierry Goubier thierry.goub...@gmail.com wrote: 2015-02-05 10:55 GMT+01:00 Sven Van Caekenberghe s...@stfx.eu: It is obviously a compromise (or a continuum) between abstractions and performance. I agree. With a special view in that we are in a sub domain where simple things well designed (Smalltalk, that is) are amazingly good at supporting complex designs. But there should remain a focus on efficiency (not just speed but also memory), it is hard to fix these things years later. And I like the fact that efficient code and design is often a pleasure to read and learn from :) Now, being radical: could we get rid of pragmas ? The only reason I see to them is that they allow extension by external packages, because we can't have methods which belong to two protocols (*). They are a Smalltalk-centric way of adding arbitrary metadata to methods; Smalltalk-centric in that a pragma is a Message instance, may be queried for senders, performed, etc, and that it can be parsed using the standard compiler (they add no new syntax). They have been broadly used. IME they have simplified and reduced code where ever they have been used. They don't have to be there but they're a good thing. Why do you want to get rid of them? Because the they have simplified and reduced code where ever they have been used is wrong. I just have to give you a counter example: OK, the claim is too strong. But they /have/ simplified code in cases where they're appropriate. And I can cite several examples. One of the uses of pragmas is associating methods containing Gui commands or settings to specific objects. Based on an object inspected or selected, you search among all its methods the ones containing a specific pragma (and you order them by a parameter to that pragma, if you want), and you execute that method to retrieve the objects you want (presentations, menu commands, shortcuts, you name it, I use it :)). The code to do that is exactly as long as the one which, on the same object, retrieve all methods under a certain protocol (the latter being faster than the pragma one, to boot). Each method is one line longer (the pragma). Each such method usually has in its name a copy of the pragma (gtInspectorXXX methods, I'm looking at you), because of course this is far more user friendly to indicate its purpose in the method name than in only the pragma. (There are two more arguments for the use of pragmas in that context, one which has a direct counter-example, one which hasn't: ) Moreover, the semantic of pragmas is interesting to describe, and in some cases, require a good amount of dark magic about a global object listening to all methods changes and capturing (and executing) certain methods in a vague relation about when this is going to happen, or being triggered on specific system events (main menu rebuilding, anyone?). The funny thing is to see that pattern visible on a profile when loading packages (talk of a scalable approach). But triggering in the background happens for maintaining change sets, notifying other clients too. It's not as if pragmas introduced such triggering; that kind of triggering has been in use for a long time. And being able to reshape the GUI automatically is very useful. I don't contest the possibilities, it's just that they add a significant layer of complexity when non mastered (how many Pharo developpers know which event you have to register to to receive all new methods notifications? Is that documented in one of the books?), and that, except for using them as primitives or for extensibility, I see other syntaxes and smalltalk code which are simpler. A good example is that the pragma syntax is never included in the one page Smalltalk syntax description :) (and yes, I'm biassed) Then you're the right person to give me counter arguments... (Now, I'd look differently at pragmas used for gradual typing and so on... But even for something like FFI, I'd seriously prefer to have Smalltalk calls to describe the call and its arguments than a kind of script hidden inside pragmas, just for the discoverability and because it makes one less idiom to deal with) Why? A good use of pragmas is to associate meta data with a particular method. Having calls off to the side always introduces the need for book-keeping to keep those methods off to the side in sync with the methods they're describing. Typically everyone rolls their own. But here we're adding a level of triggering just to keep the metadata methods in sync. I agree with the metadata, but I'd prefer a
Re: [Pharo-dev] Parsing float difference between 2.0 and 3.0, was it on purpose?
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. 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.58500098e04’”. If it’s about being similar to the other languages, we can also decide does it make sense to have a +2 literal. Uko On 06 Feb 2015, at 09:04, Marcus Denker marcus.den...@inria.fr wrote: On 06 Feb 2015, at 09:02, stepharo steph...@free.fr wrote: Le 5/2/15 10:40, Sven Van Caekenberghe a écrit : On 05 Feb 2015, at 10:36, Ben Coman b...@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
Re: [Pharo-dev] Switching to Pharo from Visualworks
On 06.02.2015 10:52, Guillermo Polito wrote:
Well, but imagine how complex that bootstrap becomes when you want to
add to your classes:
- traits
- layouts
- slots
...
And expressing all that in C also :)
I don't want to imply it's easy.
I once tried to decompose a squeak image, serialize the contents and
then try to create a new working environment from that. I finaly gave up
when I got { One step forth, Two steps forth, One step back, Two
steps back}* in any number of combinations...
The image is a a) crafted artefact, not a b) generated one, but I think
pharo is on a good path from a = b.
Re: [Pharo-dev] ||
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.shea...@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
Re: [Pharo-dev] Switching to Pharo from Visualworks
Looking at Pharo, it appears to me to be suffering the same bloat issues as Squeak. Well if you say that it is that you are just looking at the tip of iceberg. This is not for fun that we are massively working on cleaning dependencies and removing wrong code or rewriting it. In the coming months we will work on putting in place our bootstrapping kernel. There are no Smalltalk able to do that right now. Bootstrapping means a lot in term of quality. But we have some work to get there and we are busy with our real work (publishing papers). I think the problem is that people always look at an artefact as “this what they want” as opposed to “this is just an imperfect snapshot of steps towards what we want”. e.g. Morphic still is a *mess*. We have some things started (e.g. Anthens) that will, when they are finished, allow us to simplify things. But right now they are just duplication. Some of the things are just “scaffolding” for better solutions in the future. So Pharo4 is just a snapshot of a tiny increment. Pharo5 will be another. And so on. One thing one needs to see is that only the things that are done are done. This is sometimes to exhausting: even the most trivial, obvious thing needs someone to actually do it. Marcus
Re: [Pharo-dev] Switching to Pharo from Visualworks
Well, but imagine how complex that bootstrap becomes when you want to add to your classes: - traits - layouts - slots ... And expressing all that in C also :) El Fri Feb 06 2015 at 10:47:19 AM, Markus Fritsche mfrits...@reauktion.de escribió: On 06.02.2015 09:33, stepharo wrote: In the coming months we will work on putting in place our bootstrapping kernel. There are no Smalltalk able to do that right now. GNU Smalltalk does just that, if it doesn't find an image, it will be bootstrapped by using the shipped .st fileouts. A bit of cheating is involved, a compiler initialization is implemented on the VM side. So I would say there are no Smalltalk that are able to do that right now the way we want to do it :-P (Pissing at the door contest, to refer to another unquoted metaphor :-D)
Re: [Pharo-dev] Switching to Pharo from Visualworks
On Fri, 2015-02-06 at 10:47 +0100, Markus Fritsche wrote: On 06.02.2015 09:33, stepharo wrote: In the coming months we will work on putting in place our bootstrapping kernel. There are no Smalltalk able to do that right now. GNU Smalltalk does just that, if it doesn't find an image, it will be bootstrapped by using the shipped .st fileouts. Smalltalk/X does that too. It does not even need .st fileouts at bootstrapping time to come up without an image. Jan A bit of cheating is involved, a compiler initialization is implemented on the VM side. So I would say there are no Smalltalk that are able to do that right now the way we want to do it :-P (Pissing at the door contest, to refer to another unquoted metaphor :-D)
Re: [Pharo-dev] ||
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. 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.mira...@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
Re: [Pharo-dev] [Pharo-users] spotter preview
Hi, I really like Spotter. The preview feature makes me think that would be useful to have it in code completion. So often I use the wrong method because completion does not display class name. The ability to have code preview in code completion (and maybe class hierarchy too) would make me open far less browser I think. An easy first step may be that when I type Shift+enter to open Spotter it copies the word where the cursor is placed in a text editor in the Spotter search field. Cheers, Laurent Le lun. 2 févr. 2015 à 22:02, Tudor Girba tu...@tudorgirba.com a écrit : Hi, The Glamorous Team is happy to present a new feature in Spotter: preview (you toggle it with Cmd+p). We think this boosts the usefulness of the Spotter interface significantly. For more details, please take a look at: http://www.humane-assessment.com/blog/boosting-gtspotter-with-preview This is available in the Moose image, and it will soon be integrated in the Pharo one. Please let us know what you think. Cheers, Doru -- www.tudorgirba.com Every thing has its own flow
[Pharo-dev] SmallInteger asByteArray for negative numbers
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: 10) allSatisfy: [ :int | int asByteArray = int negated asByteArray ] “true Cheers, Alejandro
Re: [Pharo-dev] Metacello + Filetree
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.goub...@gmail.com: 2015-02-05 13:26 GMT+01:00 Sebastian Tleye sebastian.tl...@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.stinckw...@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.goub...@gmail.com wrote: 2015-02-05 11:27 GMT+01:00 Sebastian Tleye sebastian.tl...@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.goub...@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.tl...@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
Re: [Pharo-dev] Switching to Pharo from Visualworks
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 s...@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.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Switching to Pharo from Visualworks
I have a few questions: Why don't you all use a 6-paned browser (called the package browser in Squeak) and control the introduction of top-level meta-categories? Because you have tags and you can filter packages. @Stephen, I don't know of the six panelled browser you refer to, but presumably the tree list in the package pane of Pharo's System Browser accounts for one of those two of those six panes e.g. expand the AST-Core package ? @General, btw is it possible to have more levels in the package pane, so that all the AST packages appear under a single first level entry AST ? I really did like the initial Pharo mission statement of making a tighter, cleaner open-source ST80 implementation. @Stephen, Do you refer to Pharo's general mission or the Pharo Vision document [1] which details a few specific items targeted for improvement, noting that several of those items have already been completed. [1] https://gforge.inria.fr/frs/download.php/30434/*PharoVision*.pdf cheers -ben
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/40479 Home: https://github.com/pharo-project/pharo-core
[Pharo-dev] [pharo-project/pharo-core] ccc6b1: 40479
Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: ccc6b1a77fe84d7d9b93d031c81095ae0fb5f28a https://github.com/pharo-project/pharo-core/commit/ccc6b1a77fe84d7d9b93d031c81095ae0fb5f28a Author: Jenkins Build Server bo...@pharo-project.org Date: 2015-02-06 (Fri, 06 Feb 2015) Changed paths: A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script479.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40479.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Slot.package/ClassModification.class/instance/accessing/additions.st A Slot.package/ClassModification.class/instance/accessing/removals.st A Slot.package/Slot.class/instance/meta-object-protocol/installingIn_.st A Slot.package/Slot.class/instance/meta-object-protocol/removingFrom_.st M Slot.package/Slot.class/instance/queries/definingClass.st M Slot.package/SlotClassBuilder.class/instance/initialize-release/build.st Log Message: --- 40479 14877 InstanceVariableSlot#definingClass does not work for vars from the class side https://pharo.fogbugz.com/f/cases/14877 14876 Add call back in ClassBuilder to call slots when building a class https://pharo.fogbugz.com/f/cases/14876 http://files.pharo.org/image/40/40479.zip
Re: [Pharo-dev] SmallInteger asByteArray for negative numbers
One more thing: accessing the integer bytes means accessing the details of internal representation... But if you look a bit deeper, you'll discover that: - SmallInteger use 2-complement internally (not accounting for immediate tag bits) - LargeInteger use sign-magnitude internally. So to maintain some uniformity at Integer level, and having all kind of sub-instances behaving identically, we have to cheet. As Sven said, in 2-complement we could model the high bits as an infinite sequence of 1... Not convenient for converting to a finite ByteArray, so we have chosen to behave as if integers were sign-magnitude encoded... Funnily, for bit-ops (bitAnd: bitOr: etc...) we have chosen another paradigm: behave as if integers were 2-complement encoded. 2015-02-06 15:48 GMT+01:00 Sven Van Caekenberghe s...@stfx.eu: Alejandro, On 06 Feb 2015, at 15:10, Alejandro Infante alejandroinfant...@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: 10) allSatisfy: [ :int | int asByteArray = int negated asByteArray ] “true Cheers, Alejandro (These kinds of questions should be asked on pharo-us...@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
Re: [Pharo-dev] [Slots] Invisible Slots
On 06 Feb 2015, at 11:50, Marcus Denker marcus.den...@inria.fr wrote:
Next: When building classes with Slots, the class builder need to call back
on the slot and hand the class to each. Then the slot
can reflectively change the class, e.g. the PropertySlot will check if there
is already a hidden property base slot and if not, add it
reflectively).
This is now done:
https://pharo.fogbugz.com/f/cases/14876/Add-call-back-in-ClassBuilder-to-call-slots-when-building-a-class
For playing with this, in 479:
InstanceVariableSlot subclass: #AccessorSlot
slots: { }
classVariables: { }
category: ‘Package'
two methods, #installingIn and #removingFrom:, which are called by the class
builder:
installingIn: aClass
| reader writer |
reader := String streamContents: [ :str |
str
nextPutAll: self name;
cr;tab;
nextPutAll: ' ^';
nextPutAll: self name.
].
writer := String streamContents: [ :str |
str
nextPutAll: self name;
nextPutAll: ': anObject';
cr;tab;
nextPutAll: self name;
nextPutAll: ':= anObject.'.
].
aClass compile: reader classified: 'accessing'.
aClass compile: writer classified: 'accessing’.
removingFrom: aClass
aClass removeSelector: self name.
aClass removeSelector: self name asMutator.
Now we can make a class and see how the accessors are automatically added (and
removed when the slot is removed):
Object subclass: #TT
slots: { # = AccessorSlot }
classVariables: { }
category: ‘Package'
NOTE: this is an example of what can be done with Slots. It is *not* an example
of what *should* be done with Slots.
(this we only will know after using them for a while).
Marcus
Re: [Pharo-dev] ||
On Fri, Feb 6, 2015 at 1:58 AM, Thierry Goubier thierry.goub...@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. There's a third use that is, I think, the most powerful. Maybe you see this as the same as 1, but I don't. The method is a component to be included in some larger structure, e.g. it is an action method on a menu, or it is an implementation of a pane in an inspector. The pragma is the message to be sent to the object that manipulates that larger structure to add the method to it. This is how menu pragmas work in VW. There is an object called a MenuBuilder. To add a method to a menu (and which menu is described by the pragma) the menu builder sets the method as its current method and then performs the pragma. The parameters in the pragma allow the MenuBuilder to add the method in the right way to the menu. But the execution of the pragma is what actually adds the mehtod to the menu. So its a combination of specification and execution. 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. Yes, it's right to say they have been integrated (but no documented). 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. I think whether methods are objects or text is in the eye of the beholder. From my perspective methods /are/ objects. The textual display and compilation of them is only the conventional programmer view of them. Bu from a system perspective methods are objects. Look for example at all the debugger machinery. That is largely concerned with bytecodes in method objects. 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. I have no problem with your criticism of pragmas used for categorisation. Method categories are already there and sometimes much more appropriate than pragmas. For example, in the SPur bootstrap the methods to be added or modified in Spur are included in categories of SpurBootstrapPrototypes and its subclasses. If there were pragmas in these methods then the pragmas would be copied into Spur, which is not at all what I want. Instead I copy across the methods in the relevant categories. But this not a complete solution feels to me an unfair criticism. Pragmas are what they are and they can do a lot. But no part of the system does everything. A system is composed of components. 2015-02-05 22:47 GMT+01:00 Eliot Miranda eliot.mira...@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
Re: [Pharo-dev] Switching to Pharo from Visualworks
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 s...@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.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] [Slots] Invisible Slots
Next: When building classes with Slots, the class builder need to call back on the slot and hand the class to each. Then the slot can reflectively change the class, e.g. the PropertySlot will check if there is already a hidden property base slot and if not, add it reflectively). This is now done: https://pharo.fogbugz.com/f/cases/14876/Add-call-back-in-ClassBuilder-to-call-slots-when-building-a-class Marcus
Re: [Pharo-dev] SmallInteger asByteArray for negative numbers
Alejandro, On 06 Feb 2015, at 15:10, Alejandro Infante alejandroinfant...@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: 10) allSatisfy: [ :int | int asByteArray = int negated asByteArray ] “true Cheers, Alejandro (These kinds of questions should be asked on pharo-us...@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
Re: [Pharo-dev] [pharo-project/pharo-core] 6a5096: 40477
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.den...@inria.fr wrote: On 06 Feb 2015, at 09:07, Marcus Denker marcus.den...@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
[Pharo-dev] [Pharo CI] Jenkins down 10/11 Feb
Hi, There will a big update of the Inria CI infrastructure. On 10 Feb the system will go offline 5PM Paris time, it will be online the 12th hopefully latest. Why? For now the system just supports Win and Linux. This update will add the base for MacOS vitual servers. (If you wonder how it works now: we have a non-virtual Mac in our office that runs all mac builds…) Marcus
Re: [Pharo-dev] Switching to Pharo from Visualworks
Yes, but that is not really provided as a #catalog* method, is it ? There is #catalogDescription, but that is some lines of text. There should be something like #catalogLabel for a sjort one-line title style label. On 06 Feb 2015, at 16:26, Esteban Lorenzano esteba...@gmail.com wrote: there should be both: a name and a category Seaside - Web framework Zinc - HTTP server etc. Esteban On 06 Feb 2015, at 16:16, Marcus Denker marcus.den...@inria.fr wrote: 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 s...@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.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] ||
On Fri, Feb 6, 2015 at 5:58 PM, Thierry Goubier thierry.goub...@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 HaltsignalerContext (or into a helper method called from #singalerContext) * have a convention for a certain protocol to hold these methods, which HaltsignalerContext 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.mira...@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
Re: [Pharo-dev] Switching to Pharo from Visualworks
there should be both: a name and a category Seaside - Web framework Zinc - HTTP server etc. Esteban On 06 Feb 2015, at 16:16, Marcus Denker marcus.den...@inria.fr wrote: 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 s...@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.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Switching to Pharo from Visualworks
El Fri Feb 06 2015 at 4:30:10 PM, Eliot Miranda eliot.mira...@gmail.com escribió: On Feb 6, 2015, at 1:52 AM, Guillermo Polito guillermopol...@gmail.com wrote: Well, but imagine how complex that bootstrap becomes when you want to add to your classes: - traits - layouts - slots ... And expressing all that in C also :) Surely the bootstrap doesn't have to be expressed in C?!?! It can be expressed in Smalltalk and still be a bootstrap right? :) Hahaha, that was my point. Expressing it in C would be a mess. That's why we do it in Smalltalk.
Re: [Pharo-dev] ||
Hi Thierry, On Fri, Feb 6, 2015 at 9:29 AM, Eliot Miranda eliot.mira...@gmail.com wrote: On Fri, Feb 6, 2015 at 1:58 AM, Thierry Goubier thierry.goub...@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. There's a third use that is, I think, the most powerful. Maybe you see this as the same as 1, but I don't. The method is a component to be included in some larger structure, e.g. it is an action method on a menu, or it is an implementation of a pane in an inspector. The pragma is the message to be sent to the object that manipulates that larger structure to add the method to it. This is how menu pragmas work in VW. There is an object called a MenuBuilder. To add a method to a menu (and which menu is described by the pragma) the menu builder sets the method as its current method and then performs the pragma. The parameters in the pragma allow the MenuBuilder to add the method in the right way to the menu. But the execution of the pragma is what actually adds the mehtod to the menu. So its a combination of specification and execution. 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. Yes, it's right to say they have been integrated (but no documented). 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. I think whether methods are objects or text is in the eye of the beholder. From my perspective methods /are/ objects. The textual display and compilation of them is only the conventional programmer view of them. Bu from a system perspective methods are objects. Look for example at all the debugger machinery. That is largely concerned with bytecodes in method objects. 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. I have no problem with your criticism of pragmas used for categorisation. Method categories are already there and sometimes much more appropriate than pragmas. For example, in the SPur bootstrap the methods to be added or modified in Spur are included in categories of SpurBootstrapPrototypes and its subclasses. If there were pragmas in these methods then the pragmas would be copied into Spur, which is not at all what I want. Instead I copy across the methods in the relevant categories. But this not a complete solution feels to me an unfair criticism. Pragmas are what they are and they can do a lot. But no part of the system does everything. A system is composed of components. Or are you talking about the lack of class pragmas? This is a point. But classes already have an executable hook they can use for system modification, their class-side initialize and obsolete methods. That's been used for a long time to address system modification needs on installing and removing classes. So form that perspective there's less of a need to class pragmas. Instead we're focussing on more specialised class definition facilities such as slots, which are intrinsic to classes, i.e. define the class itself, rather than pragmas, which are extrinsic to methods in that they define how methods interact in the system outside themselves. 2015-02-05 22:47 GMT+01:00 Eliot Miranda eliot.mira...@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
Re: [Pharo-dev] Switching to Pharo from Visualworks
2015-02-06 17:05 GMT+01:00 Ben Coman b...@openinworld.com: @General, btw is it possible to have more levels in the package pane, so that all the AST packages appear under a single first level entry AST ? Yes @Ben, but it's not yet in Nautilus. I have a few experiments in that in AltBrowser, such as: - pre-existing hierarchical categories for packages (with about 5 to 20 entries), - naming-based matching (i.e. all AST packages are under AST), [image: Images intégrées 1] - catalogKeyword-based categories (for configurations with keyword entries, they are moved in the right top-level package category), - configuration naming based category creation (see above), and - user adjustable hierarchies (i.e. you can reorganize the tree if you prefer and save it as a setting). Some of it needs some improvement, because configurations are often not that well organised (many don't have keywords at all), naming conventions in configurations aren't reliable, and I don't grok Monticello/Metacello well enough to explore configurations and baselines the way Versionner does. Bringing that to Nautilus may not be that easy. The left pane is fairly narrow, and not very tall due to the filter box (which could auto-hide instead of being allways there). The same goes for the 6 panes idea: it's very wide and, compared to the past, we're dealing with longuer entries (icons, indentation) which translate into larger panes. Thierry
Re: [Pharo-dev] ||
Hi Frank, On Fri, Feb 6, 2015 at 2:29 AM, Frank Shearar frank.shea...@gmail.com wrote: On 5 February 2015 at 21:20, Thierry Goubier thierry.goub...@gmail.com wrote: 2015-02-05 21:28 GMT+01:00 Eliot Miranda eliot.mira...@gmail.com: On Thu, Feb 5, 2015 at 11:34 AM, Thierry Goubier thierry.goub...@gmail.com wrote: 2015-02-05 18:51 GMT+01:00 Eliot Miranda eliot.mira...@gmail.com: On Thu, Feb 5, 2015 at 2:31 AM, Thierry Goubier thierry.goub...@gmail.com wrote: 2015-02-05 10:55 GMT+01:00 Sven Van Caekenberghe s...@stfx.eu: It is obviously a compromise (or a continuum) between abstractions and performance. I agree. With a special view in that we are in a sub domain where simple things well designed (Smalltalk, that is) are amazingly good at supporting complex designs. But there should remain a focus on efficiency (not just speed but also memory), it is hard to fix these things years later. And I like the fact that efficient code and design is often a pleasure to read and learn from :) Now, being radical: could we get rid of pragmas ? The only reason I see to them is that they allow extension by external packages, because we can't have methods which belong to two protocols (*). They are a Smalltalk-centric way of adding arbitrary metadata to methods; Smalltalk-centric in that a pragma is a Message instance, may be queried for senders, performed, etc, and that it can be parsed using the standard compiler (they add no new syntax). They have been broadly used. IME they have simplified and reduced code where ever they have been used. They don't have to be there but they're a good thing. Why do you want to get rid of them? Because the they have simplified and reduced code where ever they have been used is wrong. I just have to give you a counter example: OK, the claim is too strong. But they /have/ simplified code in cases where they're appropriate. And I can cite several examples. One of the uses of pragmas is associating methods containing Gui commands or settings to specific objects. Based on an object inspected or selected, you search among all its methods the ones containing a specific pragma (and you order them by a parameter to that pragma, if you want), and you execute that method to retrieve the objects you want (presentations, menu commands, shortcuts, you name it, I use it :)). The code to do that is exactly as long as the one which, on the same object, retrieve all methods under a certain protocol (the latter being faster than the pragma one, to boot). Each method is one line longer (the pragma). Each such method usually has in its name a copy of the pragma (gtInspectorXXX methods, I'm looking at you), because of course this is far more user friendly to indicate its purpose in the method name than in only the pragma. (There are two more arguments for the use of pragmas in that context, one which has a direct counter-example, one which hasn't: ) Moreover, the semantic of pragmas is interesting to describe, and in some cases, require a good amount of dark magic about a global object listening to all methods changes and capturing (and executing) certain methods in a vague relation about when this is going to happen, or being triggered on specific system events (main menu rebuilding, anyone?). The funny thing is to see that pattern visible on a profile when loading packages (talk of a scalable approach). But triggering in the background happens for maintaining change sets, notifying other clients too. It's not as if pragmas introduced such triggering; that kind of triggering has been in use for a long time. And being able to reshape the GUI automatically is very useful. I don't contest the possibilities, it's just that they add a significant layer of complexity when non mastered (how many Pharo developpers know which event you have to register to to receive all new methods notifications? Is that documented in one of the books?), and that, except for using them as primitives or for extensibility, I see other syntaxes and smalltalk code which are simpler. A good example is that the pragma syntax is never included in the one page Smalltalk syntax description :) (and yes, I'm biassed) Then you're the right person to give me counter arguments... (Now, I'd look differently at pragmas used for gradual typing and so on... But even for something like FFI, I'd seriously prefer to have Smalltalk calls to describe the call and its arguments than a kind of script hidden inside pragmas, just for the discoverability and because it makes one less idiom to deal with) Why? A good use of pragmas is to associate meta data with a particular method. Having calls off to the side always introduces the need for book-keeping to keep those methods
Re: [Pharo-dev] SmallInteger asByteArray for negative numbers
I was going to complain about expecting such niceties as a built in 2s-complement rather than program it myself (I am a bit rusty on such matters), but when I look what should I find? (-123 asTwosComplement: 16r) asByteArray. = #[255 255 255 133] cheers -ben Hi Ben, You might want to look at http://www.squeaksource.com/TwosComplement Dave
Re: [Pharo-dev] SmallInteger asByteArray for negative numbers
On Fri, Feb 6, 2015 at 10:48 PM, Sven Van Caekenberghe s...@stfx.eu wrote: Alejandro, On 06 Feb 2015, at 15:10, Alejandro Infante alejandroinfant...@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: 10) allSatisfy: [ :int | int asByteArray = int negated asByteArray ] “true Cheers, Alejandro (These kinds of questions should be asked on pharo-us...@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 I was going to complain about expecting such niceties as a built in 2s-complement rather than program it myself (I am a bit rusty on such matters), but when I look what should I find? (-123 asTwosComplement: 16r) asByteArray. = #[255 255 255 133] cheers -ben
Re: [Pharo-dev] ||
Hi Ben, 2015-02-06 16:03 GMT+01:00 Ben Coman b...@openinworld.com: On Fri, Feb 6, 2015 at 5:58 PM, Thierry Goubier thierry.goub...@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 HaltsignalerContext (or into a helper method called from #singalerContext) * have a convention for a certain protocol to hold these methods, which HaltsignalerContext 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. Yes, I agree with your assessment. Solution 2 require multiple protocols for a single method to be extensible, and this usage is perfect for metadata associated with the method. 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 The good old finder has a pragmas search mode which allows for a bit of discoverability (pragma users), but it doesn't link to the code exploiting the pragmas. Do you know if we have something specific on SmartSuggestions for pragmas? Thierry
