In P7 scrpt variable to tmp when in debugger
Locked
1234
... 6
1234
... 6
In P7 scrpt variable to tmp when in debugger
 
|
Hi,
When an executed script throws an error, in the debugger the script lost its variable names and the code is not exactly the same. Any idea why? See screenshot Thanks Hilaire -- Dr. Geo http://drgeo.eu |
UnammedVariable.png (369K)
Re: In P7 scrpt variable to tmp when in debugger
|
What happens if you debug the script starting with a "self halt" ? Are the variables there with their original name? looks like decompiled code. A problem with your .sources file?
----------------- Benoît St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero". (A. Einstein)
On Thursday, April 12, 2018, 10:11:37 a.m. EDT, Hilaire <[hidden email]> wrote:
Hi, When an executed script throws an error, in the debugger the script lost its variable names and the code is not exactly the same. Any idea why? See screenshot Thanks Hilaire -- Dr. Geo |
Re: In P7 scrpt variable to tmp when in debugger
|
|
In reply to this post by HilaireFernandes
> On 12 Apr 2018, at 16:10, Hilaire <[hidden email]> wrote: > > Hi, > > When an executed script throws an error, in the debugger the script lost its variable names and the code is not exactly the same. > > Any idea why? > Hello, I changed the way code is compiled for #evaluate: to speed it up, but it turns out that having nice vars is actually more important than speed in most cases. I will change this again and just add it as an optional feature (you then can set an option if you need speed, but the default will be to keep the var names). For an intermediate fix, you can change in OpalCompiler>>#evaluate the send of #generate to #generateWithSource. Marcus |
Re: In P7 scrpt variable to tmp when in debugger
|
|
Hi Marcus, Benoit,
Nice to know. I was testing in a set up with both .changes and source files. So I was suspecting something like what your described. I can imagine in production code your feature to speed up compilation will be appreciated. For Dr. Geo and Smalltalk sketch, it is better to have variable names. Thanks Hilaire Le 12/04/2018 à 16:31, Marcus Denker a écrit : > Hello, > > I changed the way code is compiled for #evaluate: to speed it up, but it turns out that having nice vars is actually more important than > speed in most cases. > > I will change this again and just add it as an optional feature (you then can set an option if you need speed, but the default will be to keep the > var names). > > For an intermediate fix, you can change in OpalCompiler>>#evaluate the send of #generate to #generateWithSource. > > Marcus -- Dr. Geo http://drgeo.eu |
Re: In P7 scrpt variable to tmp when in debugger
|
|
> On 12 Apr 2018, at 17:06, Hilaire <[hidden email]> wrote: > > Hi Marcus, Benoit, > > Nice to know. I was testing in a set up with both .changes and source files. So I was suspecting something like what your described. I can imagine in production code your feature to speed up compilation will be appreciated. For Dr. Geo and Smalltalk sketch, it is better to have variable names. > I should have a fix ready tomorrow. > Thanks > > Hilaire > > Le 12/04/2018 à 16:31, Marcus Denker a écrit : >> Hello, >> >> I changed the way code is compiled for #evaluate: to speed it up, but it turns out that having nice vars is actually more important than >> speed in most cases. >> >> I will change this again and just add it as an optional feature (you then can set an option if you need speed, but the default will be to keep the >> var names). >> >> For an intermediate fix, you can change in OpalCompiler>>#evaluate the send of #generate to #generateWithSource. >> >> Marcus > > -- > Dr. Geo > http://drgeo.eu > > > |
Re: In P7 scrpt variable to tmp when in debugger
|
|
Thanks.
Le 12/04/2018 à 17:18, Marcus Denker a écrit : > I should have a fix ready tomorrow. -- Dr. Geo http://drgeo.eu |
Where do we go now ?
|
|
In reply to this post by HilaireFernandes
Hello guys, Just a quick word to get some things straight because, quite frankly, I really don't know where we're heading. When Pharo started, the goal was to depart from Squeak and do a *major clean up* of all the code, especially Morphic. The promise of a new, clean & lean Smalltalk attracted a lot of people. And then... I'm looking at the Pharo 7.0 image right now and I just don't get where we're heading. Every Pharo release gets bigger, and bigger, and bigger. I don't mind the environment getting bigger if it adds functionalities or new tools but that's not quite the case here. LOTS of stuff is just duplicated. Do we really need 2 code completion classes (NECController, NOCController) ? Do we really need 2 system browsers (Nautilus, Calypso)? Do we really need 2 compilers (OpalCompiler, Compiler) ? Do we really need 8 delay schedulers (DelayMicrosecondScheduler, DelayMillisecondScheduler, DelayNullScheduler, DelayExperimentalSpinScheduler, DelaySpinScheduler, DelayTicklessScheduler, DelayExperimentalCourageousScheduler, DelayExperimentalSemaphoreScheduler) ? Do we really need 2 inspectors (GTInspector, EyeInspector) ? Do we really need 2 workspaces (GTPlayground, Workspace) ? Et cetera. Et cetera. Et cetera. I could go on, and on, and on... Pharo 5.1 had 5885 classes. Pharo 6.1 had 6481 classes. Pharo 7.0 alpha has 7612 classes. Can you see a trend? Pharo 5.1 had 416 preference settings. Pharo 6.1 had 494 preference settings. Pharo 7.0 alpha has 662 preference settings. Can you see a trend? Pharo 5.1 had a 27.44 MB image. Pharo 6.1 had a 35.18 MB image. Pharo 7.0 alpha has a 47.97 MB image. Can you see a trend? Add to that the fact that Pharo is a nightmare when you want to port code. Just with the 7.0 release, 61 classes will be deprecated (and lots more to come if you search for the string "deprecated" into the code, most of the time hidden in the comments of the soon-to-be-deprecated-in-Pharo-8-I-guess classes). You have code that deals with sockets, should you use the old Socket classes or convert everything to Zodiac? And why do we keep both "frameworks" in the image ? Pharo hasn't been backward compatible with "old socket classes" a looooooong time ago anyway! You have code that deals with dependencies, should you use the old dependents mechanism or convert everything to announcements? UI speaking, what framework should anyone use ? Athens? Something else? You have code that deals with streams, should you use the old stream classes or convert everything to Zinc ? And why do we keep both "frameworks" in the image ? Pharo hasn't been backward compatible with the old stream classes a looooooong time ago anyway! So what's the plan? For instance, should I keep using the Nautilus Browser or I should switch to the Calypso browser and get used to it because Nautilus will be deprecated? Or should I just don't care because a third system browser will be added in Pharo 8 just because "it's cool, let's add this one too!" ? Couldn't we just decide on what's "official" and what's a goodie or an external optional tool/package/framework the same way all other Smalltalks do? If you say Calypso is the official & supported browser, fine! Then just get Nautilus out of the image, create a nice loadable package for it and if someone prefers Nautilus, they'll just have to load it into the image, the same way VW has a gazillion optional tools/packages/frameworks you can load from a parcel! Whenever I get asked a simple question by a newbie like "Oh, which system browser should I use?", quite frankly, I don't know what to answer. Did we include Calypso to deprecate Nautilus later? Is Calypso just a proof of concept? Is it just an optional tool? What about all those delay schedulers? "I loaded this code from SqueakSource and it just doesn't work". Should I help the guy to fix it or just tell him to convert all the code to the corresponding framework in Pharo? Perhaps a little bit of clarity and details about what's coming and what's the plan would be beneficial to a lot of us. ----------------- Benoît St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero". (A. Einstein) |
|
|
It is true that there are many things in there. New tools have to be finished before the old ones can be removed (there was a time where refactorings were not in Calypso). But for a real project, one is settling for a version and a toolset. I am not really keen to migrate Pharo projects from one version to another and some deprecations seems rather gratuitous sometimes. The world also moves forward and it shows in the image. I think that Iceberg has swallowed a lot of bandwidth and as a result other elements are in need of more love. Pharo7 is unreleased yet. Some say something is great by version 10. 3 versions to go. I consider Pharo 7 as a great piece of kit but unusable for my current work. There are many new things to learn in there. When is too much too much? Also, simplifications are breaking things in unexpected ways (like the #atEnd thing). I am glad 6.1 gets backports and new releases for sure. Phil On Fri, Apr 13, 2018, 07:53 Benoit St-Jean via Pharo-users <[hidden email]> wrote:
|
|
|
In reply to this post by Pharo Smalltalk Users mailing list
On 13 April 2018 at 13:53, Benoit St-Jean via Pharo-users <[hidden email]> wrote:
This should have been cleaned up a while ago. Thanks for the bump. I'll get to it. However note, that half of those have not more than two methods, so are not contributing much to the size of the Image.
I guess you are looking for... cheers -ben |
|
|
In reply to this post by Pharo Smalltalk Users mailing list
Hi,
Pharo 7.0 is a development version. Before is releases most duplicated things you mention here will be gone: - Nautilus - Compiler - EyeInspector Workspace could be gone but we need a fallback in case the other more potent tools fail. Schedulers are still necessary.
Pharo 5.1 didn’t have : - GTTools - Iceberg - Epicea - and many others.
If you do not want we to remove classes, how do you want we to go “smaller" and cleaner?
Zodiac relies on Sockets, there is not duplication there.
you got me here. but removing takes time… you are free to contribute with fixes :)
yes, I think Athens should not be part of the image but a loadable package.
again, you are mixing pearls and apples here. (and btw, there was a HUGE refactor of streams on P7)
The plan is continue improving slowly but steady… things takes time.
You should read this list with more attention. We told at least 10 times Nautilus is going to be removed. We told it in presentations. We told it in tech talks. I don’t know how else we could tell it. Maybe a HUGE banner in our site? “HEY YOU, READER: NAUTILUS WILL BE REMOVED!"
if there is a corresponding framework yes. Problem is that people tends to believe a package from squeaksource not loading in P7 is our fault and not the responsibility of the package maintainer (or the one wanting to use it).
Perhaps a little bit of reading? We told it, several times. You cannot take an alpha version and expect production quality. And you cannot expect that things happens magically: engineering takes a lot of time and efforts and we do our best with the resources we have as a community. This is an open source project. With perks and no so much… but the way to change things is contributing. And just to be clear: The goal of Pharo was never to be SMALL. The goal is to do a Smalltalk that is at the same time: - Clean (That DOES NOT MEANS SMALL!) - Modern - Fitting for business I’m sorry for counter-rant your rant, but while there are somethings were you are right, I find the tone of your commentary not very constructive. cheers! Esteban
|
|
|
In reply to this post by Ben Coman
I didn’t know. Thanks :)
|
|
|
In reply to this post by Pharo Smalltalk Users mailing list
On 13/04/2018 07:53, Benoit St-Jean via Pharo-users wrote:
Hi, I don't have time to answer to everything but I can give some details: - Nautilus will be removed when Calypso will be really stable (During the Calypso development if calypso breaks, you need an other browser to replace it) - The old compiler will be removed as an external project (https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/ROADMAP.md) - I think it's planned to remove the EyeInspector - Kommiter and Versionner will also be removed in next versions of Pharo "Pharo 5.1 had 5885 classes. Pharo 6.1 had 6481 classes. Pharo 7.0 alpha has 7612 classes." In general I do not like metrics in term of number of classes because I prefer a system with 7500 classes of 50 lines of code than a system of 6000 classes of 300 lines of codes. "Pharo 5.1 had 416 preference settings. Pharo 6.1 had 494 preference settings. Pharo 7.0 alpha has 662 preference settings." The number of settings is not a bad thing if it's well organized. The current problem is not the number of settings, it's more their organization. Have a nice day. :) -- Cyril Ferlicot https://ferlicot.fr |
|
|
In reply to this post by EstebanLM
As a general note, I have to say that I find amusing how people are often annoyed about the growing size of the image and the amount of classes.
We have an image that contains a full IDE which incorpores more and more modern capabilities. And you want that to stay small and fewer classes? I’m sorry but you are missing the point. More tools (or same tools enhanced) means more size and classes. Then… why the fear about classes? This is OOP. Doing classes is what we do. I prefer a new class to, for example passing same information into a dictionary. I prefer a new class over a string. I prefer a new class over a tuple. We now have slots instead symbols to express variables. I dream with even more classes: Selector, Protocol (we already have it, but we need to use it), etc., etc., etc. I will always prefer a class that defines a concept than a non-reified usage of generic classes. We need better ways to organise that information? YES! (For example I was thinking browser by default should not show “tool packages”, to reduce the amount of information). But I welcome more classes and less esoteric usages of existing ones, always. cheers, Esteban
|
|
|
In reply to this post by CyrilFerlicot
> On 13 Apr 2018, at 10:31, Cyril Ferlicot D. <[hidden email]> wrote: > > On 13/04/2018 07:53, Benoit St-Jean via Pharo-users wrote: > > Hi, > > I don't have time to answer to everything but I can give some details: > > - Nautilus will be removed when Calypso will be really stable (During > the Calypso development if calypso breaks, you need an other browser to > replace it) > - The old compiler will be removed as an external project > (https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/ROADMAP.md) > - I think it's planned to remove the EyeInspector > - Kommiter and Versionner will also be removed in next versions of Pharo > > "Pharo 5.1 had 5885 classes. Pharo 6.1 had 6481 classes. Pharo 7.0 alpha > has 7612 classes." > > In general I do not like metrics in term of number of classes because I > prefer a system with 7500 classes of 50 lines of code than a system of > 6000 classes of 300 lines of codes. amen! > > "Pharo 5.1 had 416 preference settings. Pharo 6.1 had 494 preference > settings. Pharo 7.0 alpha has 662 preference settings." > > The number of settings is not a bad thing if it's well organized. The > current problem is not the number of settings, it's more their > organization. > > Have a nice day. :) > > -- > Cyril Ferlicot > https://ferlicot.fr > |
|
|
In reply to this post by EstebanLM
Moreover, we are increasing the system modularity so more classes in the IDE does not mean that you need to have them all loaded. -- Pavel 2018-04-13 10:39 GMT+02:00 Esteban Lorenzano <[hidden email]>:
|
Re: Where do we go now ?
|
|
In reply to this post by philippeback
> On 13 Apr 2018, at 08:43, [hidden email] wrote: > > I consider Pharo 7 as a great piece of kit but unusable for my current work. There are many new things to learn in there. When is too much too much? Also, simplifications are breaking things in unexpected ways (like the #atEnd thing). Phil, Nothing fundamental will break with #atEnd. What you are reading in pharo-dev is a constructive discussion that (for me at least) started with the desire to support one very special kind of stream (stdin in C terms), something 99.99% of Pharo users have never seen, used or heard of. Zn streams have worked well and as expected for Pharo versions going back to 3, that won't change. Sven |
Re: Where do we go now ?
|
|
In reply to this post by EstebanLM
"You cannot take an alpha version and expect production quality." I'm on Windows 10, using Pharo 7.0 alpha 32 bit. Can I at least expect to be able to save code in my local Monticello repository ? It bombs. I just reported a bug! Can I expect the Windows installer for Pharo Launcher to work on Windows? It doesn't : it crashes. Can I expect Pharo Launcher (not installed from the .exe installer) to work on Windows? It just doesn't. I get all kinds of error related to WindowsStore, bad UTF-8 encoding and other things... (see https://twitter.com/smalltalkdev/status/978973863332798464) Can I expect that when looking for implementors of a method things still work? I get duplicates (see attached file). Can I expect reading input from the console to work on Windows? It doesn't. Can I expect to be able to test my stuff on Windows? That's kinda hard when Windows is always 6 months to 1 year behind VM-wise. Can I expect to be able to contribute ? That is kinda sad but all the cool scripts out there are .sh files. I'm not whining about the effort people put into this project : I'm mostly whining about duplication of effort and code and *very poor* Windows support... Just spend 2 weeks working with Pharo on Windows. You can start with version 5.1 if you want and let me know how it goes... Brace yourself, I'm telling you, you're off for a wild & unpleasant ride. ----------------- Benoît St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero". (A. Einstein) |
|
|
In reply to this post by EstebanLM
Can I expect a PR to help?
I tell you again: That tone does not helps your case, please calm down. Esteban
|
|
|
In reply to this post by EstebanLM
and btw… which part of ALPHA you do not get? Esteban
|
|
|
In reply to this post by Pharo Smalltalk Users mailing list
On 13/04/2018 11:07, Benoit St-Jean via Pharo-users wrote:
"Can I at least expect to be able to save code in my local Monticello repository ? It bombs. I just reported a bug!" "Can I expect that when looking for implementors of a method things still work? I get duplicates (see attached file)." => The meaning of alpha is that things like this can happen often. Else it would be a beta or a release version. But if you stick to use it, the bug reports are really welcomed! For the windows launcher indeed there is weird behaviour and Christophe is working on it when he gets bug reports. (https://github.com/pharo-project/pharo-launcher/issues) "Can I expect reading input from the console to work on Windows? It doesn't." What do you mean by that? Having Pharo running and the user sending input from it's CMD? I never saw an application doing that on windows. "Can I expect to be able to contribute ? That is kinda sad but all the cool scripts out there are .sh files." Which scripts? I contribute to Pharo from windows 7 and windows 10 without any script. Sometimes I have some troubles but it's only natural during the version that change all the contribution process the time it stabilize. If you have troubles on windows can you open issues please? Because most of the time I see that people complain about some bugs but some of those bugs never got a bug report. -- Cyril Ferlicot https://ferlicot.fr |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |