- Pharo-users - lists.pharo.org

Re: [Pharo-users] About GTSpotter matching

by Juraj Kubelka

Hi, #<anything> is a category filter. Try #class, #instance, etc. Wild characters are not possible to use. We are aware of this. But the case is not that simple. If I remember well, there were some performance issues. Then I have learnt that people are not aware of regular expressions or any other kind of wild-characters. Even such simple thing like #<category name> is confusing. We need to find out different way having this feature apparent. Cheers, Juraj > On Dec 5, 2015, at 20:40, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > Hi, > > are there some wildcards in GTSpotter matching? > > Currently it searches anywhere in the (method) name, which makes it hard > for shorter names, because it will match a lot of junk. > > I've also discovered (by accident), that I can use '>>#selector' to > anchor the start of the selection. ('#selector' for some reason doesn't > work). > But I would like to also search by a simple ? (any character), * (any > characters) wildcard. Is that possible? > > Additionally constraining it from the end would be also nice. > For example I want to look through #default methods, however 90% of the > matches will be junk, so I would like to write '#default$' and it will > not match '#defaultIcon', etc. > > Is this possible? > > Thanks, > -- > Peter >

Dec. 7, 2015

Re: [Pharo-users] [Pharo-dev] Help needed: old issues issue tracker entries

by Marcus Denker

The over 600 number looks scary sometimes.. but just by doing one after the other, we it is actually doable. The proof is that we closed 1587 already for Pharo5â¦ and for Pharo all versions we are at 14295 issues âdoneâ. 638 looks small compared to that. Marcus > On 07 Dec 2015, at 12:30, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Thanks a lot, Marcus for this encouragements! > > Doru > > >> On Dec 7, 2015, at 6:15 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >>> On 05 Dec 2015, at 19:31, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> >>>> On 30 Nov 2015, at 13:21, marcus.denker(a)inria.fr wrote: >>>> >>>> Hi, >>>> >>>> The issue tracker has 658 open issues. This number is more or less constant. >>>> >>> >>> down to 642! >> >> Down to 638. Can *YOU* help to get it to 637? >> >> Marcus > > -- > www.tudorgirba.com > > "We cannot reach the flow of things unless we let go." > > > >

Dec. 7, 2015

Re: [Pharo-users] [Pharo-dev] Help needed: old issues issue tracker entries

by Tudor Girba

Thanks a lot, Marcus for this encouragements! Doru > On Dec 7, 2015, at 6:15 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 05 Dec 2015, at 19:31, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >>> On 30 Nov 2015, at 13:21, marcus.denker(a)inria.fr wrote: >>> >>> Hi, >>> >>> The issue tracker has 658 open issues. This number is more or less constant. >>> >> >> down to 642! > > Down to 638. Can *YOU* help to get it to 637? > > Marcus -- www.tudorgirba.com "We cannot reach the flow of things unless we let go."

Dec. 7, 2015

Re: [Pharo-users] Help needed: old issues issue tracker entries

by Marcus Denker

> On 05 Dec 2015, at 19:31, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 30 Nov 2015, at 13:21, marcus.denker(a)inria.fr wrote: >> >> Hi, >> >> The issue tracker has 658 open issues. This number is more or less constant. >> > > down to 642! Down to 638. Can *YOU* help to get it to 637? Marcus

Dec. 7, 2015

Re: [Pharo-users] Stop Thinking in Terms of Files

by Thierry Goubier

2015-12-07 8:53 GMT+01:00 Martin BÃ¤hr <mbaehr(a)email.archlab.tuwien.ac.at>: > Excerpts from Dimitris Chloupis's message of 2015-12-07 08:24:13 +0100: > > > well, i wouldn't need or even want it in memory, so on disk is fine. > the > > > problem is more likely management of the same. browsing the changes is > not > > > really convenient. > > > There are versions already for methods. So the functionality is there. > > only if i save them in monticello though, and i can't just switch the > version > of a single method, only the whole changeset at once. in git i can limit > browsing to a specific file, and then copy an old version of a file into > the > current workspace. it is a bit crude, but it can be done. i don't see that > kind > of functionality in pharo. the data is there, but the tools to use the > data in > this specific manner are not. > They are there: I implemented and demoed what you describe as a need over git a few years ago when I started GitFileTree [1]. Then, probably over more than a year ago, Dale Henrich implemented a lot more in his environment (tode). Now, what we may conclude is that the need may not be that great. Regards, Thierry [1] http://forum.world.st/Pharo-dev-Versions-Browser-over-gitfiletree-tp4695490…

Dec. 7, 2015

Re: [Pharo-users] Stop Thinking in Terms of Files

by Martin BÃ¤hr

Excerpts from Thierry Goubier's message of 2015-12-07 08:33:03 +0100: > > the problem is more likely management of the same. browsing the changes is > > not really convenient. ideally i'd like to see versions in the > > class-browser and in the debugger, where on error i could then take a look > > at older versions for comparison, and switch to them to see if maybe the > > last change was the cause of the error. > What you describe is a GUI limitation, not the changes itself :(. A > better integration of the browser/debugger with the code versionning. > And just a local git, fossil or monticello repository would be enough. > All the pieces are there. indeed. for me that's a good enough answer for now. at least for the source versioning. i can very well imagine how to make that work. unfortunately i don't think it is enough to support the question richard received. i am still not clear how object versioning would work. i mean, i can imagine this: x := Foo new. i can now save x in a database. and i can retrieve it, and the result is the same as the original call of Foo new. but we are talking about code versioning, so presumably, i want to version the class. i guess that would need to happen in the browser too. every time a code-change is saved, a new class object is created. that needs then to be stored in the database, along with the source code. and when browsing a class, i should get a list of historical objects, just like i can get a list of historical source versions. why would i want to version the class object? to avoid recompiling it, either to save time, or because recompiling does not guarantee that we do actually get the same result because it may be affected by the environment. (i don't know if that is an issue however) do i get that right? or are there other reasons for class object versioning, if there are any at all. > As an example, it would be very easy to make AltBrowser browse all the > MC stuff, or RB changes, in addition to the normal (RPackage/Ring) live > code structure (and hence give you access to class versions, method > versions, etc...). that is the second time someone suggests altbrowser. i am going to have to look at that...) greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

Dec. 7, 2015

Re: [Pharo-users] Stop Thinking in Terms of Files

by Martin BÃ¤hr

Excerpts from Dimitris Chloupis's message of 2015-12-07 08:24:13 +0100: > > well, i wouldn't need or even want it in memory, so on disk is fine. the > > problem is more likely management of the same. browsing the changes is not > > really convenient. > There are versions already for methods. So the functionality is there. only if i save them in monticello though, and i can't just switch the version of a single method, only the whole changeset at once. in git i can limit browsing to a specific file, and then copy an old version of a file into the current workspace. it is a bit crude, but it can be done. i don't see that kind of functionality in pharo. the data is there, but the tools to use the data in this specific manner are not. > I think that changes file was created for the > precise scenarios of an image crash/ lockdown. indeed, i agree, changes are to recover from an image crash, and less useful to browse old versions of code. > But I do agree it would be useful to extend the tools working with changes > , but then none stop anyone from doing so and is not that hard to do. true, but that's not enough to use as an argument to "sell smalltalk" so i am afraid, all we can say about in-image versioning is: it's possible, but current tools don't support it. (note that i have no issue with the current state. dreaming about what we could do is nice, but it is important to be aware of what is currently well supported, and what isn't so that we avoid to oversell features that aren't practically usable.) greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

Dec. 7, 2015

Re: [Pharo-users] Stop Thinking in Terms of Files

by Dimitris Chloupis

"A Smalltalk Image is your entire system. The Image includes all the tools required to interact, customize and add functionality to your system, so Smalltalkâs IDE is a very Integrated Development Environment." Thats not the case even for someone like me that has been working with smalltalk for only 2 years. The Image is not even the engine that drives smalltalk . Thats the job of the VM that exists in a completely different universe than smalltalk. It exists in the same universe than many other languages do exists and thats the C universe, the universe of the OS. Essentially what drives your system is not smalltalk is C. The diffirence is that for a part of it that is high level enough, Slang is used, a Hybrid language between C and Smalltalk that compiles to C. So while in the image everything is , well almost everything, an object all the way down, in the VM everything is C all the way down. Ironically an image misses the most important tool to even generate this C code and thats the VMMaker that has to be installed separately. And of course there are parts of the system that are coded in pure C, like some core functionalities of the VM and of course plugins and external libraries that the image has to rely on make things happen. Of course the image is still fairly powerful, you can change the syntax, implement high level libraries, IDE tools and much more. But its not the core of the system just another essential part of it. On Mon, Dec 7, 2015 at 9:24 AM Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > >> well, i wouldn't need or even want it in memory, so on disk is fine. the >> problem is more likely management of the same. browsing the changes is not >> really convenient. ideally i'd like to see versions in the class-browser >> and >> in the debugger, where on error i could then take a look at older >> versions for >> comparison, and switch to them to see if maybe the last change was the >> cause of >> the error. >> >> greetings, martin. >> >> > There are versions already for methods. So the functionality is there. > > I disagree however with you, I think that changes file was created for the > precise scenarios of an image crash/ lockdown. In that case you may want to > go back through the code and dont remember which method was triggered or > what else was defined and created. In the case going chronologically which > is how the changes file is already organised is far more useful than going > method and class based. > > But I do agree it would be useful to extend the tools working with changes > , but then none stop anyone from doing so and is not that hard to do. >

Dec. 7, 2015

Re: [Pharo-users] Stop Thinking in Terms of Files

by Thierry Goubier

Le 07/12/2015 07:13, Martin BÃ¤hr a Ã©crit : > Excerpts from Thierry Goubier's message of 2015-12-07 06:42:51 +0100: >>> i am interested in the versioning of code and objects. >>> the poster makes a good point there. >> The traditional, full approach, would have been to use an object >> oriented database like GemStone. Anything that can version objects can >> version Smalltalk code. > > gemstone is proprietary, so that doesn't really work for me. are there alternatives? I have not looked into the alternatives. I know what is needed for a transparent OO layer for Smalltalk, and I wrote some of the necessary support code for my PhD in 1997/1998, but I never went very deep into the versionning aspect (especially the transactions, commits and conflict resolution). In short, things are available, a lot of litterature, and maybe some stuff you can rely upon (the voyage/MongoDB/Sqlite layers we have now?). >>> what if i am on a non-networked machine, running pharoNOS or even squeakNOS, >>> how would i keep old versions of my code/objects? is there any in-image >>> solution for that? >> The .changes provides that in a limited form. It would be easy to do >> better in memory, if needed. > > well, i wouldn't need or even want it in memory, so on disk is fine. For a moment, I was thinking of systems without disk at all... > the > problem is more likely management of the same. browsing the changes is not > really convenient. ideally i'd like to see versions in the class-browser and > in the debugger, where on error i could then take a look at older versions for > comparison, and switch to them to see if maybe the last change was the cause of > the error. What you describe is a GUI limitation, not the changes itself :(. A better integration of the browser/debugger with the code versionning. And just a local git, fossil or monticello repository would be enough. All the pieces are there. As an example, it would be very easy to make AltBrowser browse all the MC stuff, or RB changes, in addition to the normal (RPackage/Ring) live code structure (and hence give you access to class versions, method versions, etc...). Regards, Thierry

Dec. 7, 2015

Re: [Pharo-users] Stop Thinking in Terms of Files

by Dimitris Chloupis

> > well, i wouldn't need or even want it in memory, so on disk is fine. the > problem is more likely management of the same. browsing the changes is not > really convenient. ideally i'd like to see versions in the class-browser > and > in the debugger, where on error i could then take a look at older versions > for > comparison, and switch to them to see if maybe the last change was the > cause of > the error. > > greetings, martin. > > There are versions already for methods. So the functionality is there. I disagree however with you, I think that changes file was created for the precise scenarios of an image crash/ lockdown. In that case you may want to go back through the code and dont remember which method was triggered or what else was defined and created. In the case going chronologically which is how the changes file is already organised is far more useful than going method and class based. But I do agree it would be useful to extend the tools working with changes , but then none stop anyone from doing so and is not that hard to do.

Dec. 7, 2015