- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: gtdebugger in pharo 5.0

by Andrei Chis

On Fri, Jan 8, 2016 at 2:23 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > is there any documentation about this ? or i just look at the relevant > classes ? > Not really. Now you'll need to look in UITheme>>styleContext:from:, but I'll refactor that method shortly. > On Fri, Jan 8, 2016 at 3:20 PM Andrei Chis <chisvasileandrei(a)gmail.com> > wrote: > >> On Fri, Jan 8, 2016 at 2:09 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> >> wrote: >> >>> does the GTDebugger respect the pharo themes support or is it like >>> GTSpotter ? >>> >> >> It behaves just as GTInspector regrading the theme. Just if you are >> using a custom theme and want to have the coloring of the stack enabled you >> need to provide the appropriate colors in your theme (styleContext:from:) >> >> Cheers, >> Andrei >> >> >> >>> >>> On Fri, Jan 8, 2016 at 1:08 PM Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>>> Hi, >>>> >>>> We are about to integrate in Pharo a new member of the Glamorous >>>> Toolkit: the GTDebugger. As this is a significant change that might affect >>>> your workflow, here is some background information to help you deal >>>> with the change. >>>> >>>> First, you should know that the change is not irreversible and it is >>>> easily possible to disabled the new debugger through a setting. However, >>>> please do take the time to provide us feedback if something does not work >>>> out for you. We want to know what can be improved and we try to react as >>>> fast as we can. >>>> >>>> A practical change comes from the fact that the variables are >>>> manipulated through a GTInspector, which makes it cheaper to maintain in >>>> the longer run. >>>> >>>> While the first thing that will capture the attention is the default >>>> generic interface, the real power comes from the moldable nature of the >>>> debugger. Like all other GT tools, GTDebugger is also moldable by design. >>>> This means that we can construct custom debuggers for specific libraries at >>>> small costs (often measured in a couple of hundred lines of code). >>>> >>>> For example, the core configuration includes also the SUnit and the >>>> bytecode debugger. These are around 150 lines of code. Here is how the >>>> bytecode debugger looks like: >>>> >>>> >>>> >>>> You can find more information in an introductory overview blog post >>>> that also includes some links for further reading: >>>> >>>> http://www.humane-assessment.com/blog/gtdebugger-in-pharo/ >>>> >>>> Please let us know what you think. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "What is more important: To be happy, or to make happy?" >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)list.inf.unibe.ch >>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)list.inf.unibe.ch >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> >>> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >

Jan. 8, 2016

Re: [Pharo-dev] What is the current status of flow (flow-stack)?

by Craig Latta

Hoi Erik-- > SqueakJS seems a 'heavy' solution since I probably would like to keep > the front-end relatively thin (and not use the Morphic UI). You can also use the MVC UI, or use no Smalltalk graphics at all and just manipulate the DOM etc. via the JavaScript bridge. -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Jan. 8, 2016

Re: [Pharo-dev] [Moose-dev] Re: gtdebugger in pharo 5.0

by Dimitris Chloupis

is there any documentation about this ? or i just look at the relevant classes ? On Fri, Jan 8, 2016 at 3:20 PM Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > On Fri, Jan 8, 2016 at 2:09 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > >> does the GTDebugger respect the pharo themes support or is it like >> GTSpotter ? >> > > It behaves just as GTInspector regrading the theme. Just if you are using > a custom theme and want to have the coloring of the stack enabled you need > to provide the appropriate colors in your theme (styleContext:from:) > > Cheers, > Andrei > > > >> >> On Fri, Jan 8, 2016 at 1:08 PM Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >>> Hi, >>> >>> We are about to integrate in Pharo a new member of the Glamorous >>> Toolkit: the GTDebugger. As this is a significant change that might affect >>> your workflow, here is some background information to help you deal >>> with the change. >>> >>> First, you should know that the change is not irreversible and it is >>> easily possible to disabled the new debugger through a setting. However, >>> please do take the time to provide us feedback if something does not work >>> out for you. We want to know what can be improved and we try to react as >>> fast as we can. >>> >>> A practical change comes from the fact that the variables are >>> manipulated through a GTInspector, which makes it cheaper to maintain in >>> the longer run. >>> >>> While the first thing that will capture the attention is the default >>> generic interface, the real power comes from the moldable nature of the >>> debugger. Like all other GT tools, GTDebugger is also moldable by design. >>> This means that we can construct custom debuggers for specific libraries at >>> small costs (often measured in a couple of hundred lines of code). >>> >>> For example, the core configuration includes also the SUnit and the >>> bytecode debugger. These are around 150 lines of code. Here is how the >>> bytecode debugger looks like: >>> >>> >>> >>> You can find more information in an introductory overview blog post that >>> also includes some links for further reading: >>> >>> http://www.humane-assessment.com/blog/gtdebugger-in-pharo/ >>> >>> Please let us know what you think. >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "What is more important: To be happy, or to make happy?" >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)list.inf.unibe.ch >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev >

Jan. 8, 2016

Re: [Pharo-dev] [Moose-dev] Re: gtdebugger in pharo 5.0

by Andrei Chis

On Fri, Jan 8, 2016 at 2:09 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > does the GTDebugger respect the pharo themes support or is it like > GTSpotter ? > It behaves just as GTInspector regrading the theme. Just if you are using a custom theme and want to have the coloring of the stack enabled you need to provide the appropriate colors in your theme (styleContext:from:) Cheers, Andrei > > On Fri, Jan 8, 2016 at 1:08 PM Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> We are about to integrate in Pharo a new member of the Glamorous Toolkit: >> the GTDebugger. As this is a significant change that might affect your >> workflow, here is some background information to help you deal with the >> change. >> >> First, you should know that the change is not irreversible and it is >> easily possible to disabled the new debugger through a setting. However, >> please do take the time to provide us feedback if something does not work >> out for you. We want to know what can be improved and we try to react as >> fast as we can. >> >> A practical change comes from the fact that the variables are manipulated >> through a GTInspector, which makes it cheaper to maintain in the longer run. >> >> While the first thing that will capture the attention is the default >> generic interface, the real power comes from the moldable nature of the >> debugger. Like all other GT tools, GTDebugger is also moldable by design. >> This means that we can construct custom debuggers for specific libraries at >> small costs (often measured in a couple of hundred lines of code). >> >> For example, the core configuration includes also the SUnit and the >> bytecode debugger. These are around 150 lines of code. Here is how the >> bytecode debugger looks like: >> >> >> >> You can find more information in an introductory overview blog post that >> also includes some links for further reading: >> >> http://www.humane-assessment.com/blog/gtdebugger-in-pharo/ >> >> Please let us know what you think. >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "What is more important: To be happy, or to make happy?" >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > >

Jan. 8, 2016

Re: [Pharo-dev] Changing performance balance between CPU & non-volatile storage

by Stephan Eggermont

On 07-01-16 20:07, Ben Coman wrote: > An enlightening article (if a bit long). I wonder how non-volatile > storage being faster than a CPU might affect Pharo systems. Perhaps > the importance of migrating between live and backup Images gains in > importance to backups via files. I'm not sure what to think about it. I find it an rather vague and badly written article. 100K iops is not close to saturating what a CPU core can process. The problem is the communication and the article does a really good job at confusing me about that. Further, commercial pricing is value based, not cost. Stephan

Jan. 8, 2016

Re: [Pharo-dev] ConfigurationOfXXX package is not visible in nautilus...

by Stephan Eggermont

On 07-01-16 11:42, Stephan Eggermont wrote: > On 07-01-16 11:14, Blondeau Vincent wrote: >> It seems that any configuration loaded by Jenkins is not visible in >> Nautilus (at package level) but are accessible via the Spotter (at class >> level). Does someone know why? > > I have recently seen that error, but couldn't reproduce it. Pier3 release 3.1 on pharo 5 has that problem in build 2055 Stephan

Jan. 8, 2016

Re: [Pharo-dev] [Moose-dev] gtdebugger in pharo 5.0

by Dimitris Chloupis

does the GTDebugger respect the pharo themes support or is it like GTSpotter ? On Fri, Jan 8, 2016 at 1:08 PM Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > We are about to integrate in Pharo a new member of the Glamorous Toolkit: > the GTDebugger. As this is a significant change that might affect your > workflow, here is some background information to help you deal with the > change. > > First, you should know that the change is not irreversible and it is > easily possible to disabled the new debugger through a setting. However, > please do take the time to provide us feedback if something does not work > out for you. We want to know what can be improved and we try to react as > fast as we can. > > A practical change comes from the fact that the variables are manipulated > through a GTInspector, which makes it cheaper to maintain in the longer run. > > While the first thing that will capture the attention is the default > generic interface, the real power comes from the moldable nature of the > debugger. Like all other GT tools, GTDebugger is also moldable by design. > This means that we can construct custom debuggers for specific libraries at > small costs (often measured in a couple of hundred lines of code). > > For example, the core configuration includes also the SUnit and the > bytecode debugger. These are around 150 lines of code. Here is how the > bytecode debugger looks like: > > > > You can find more information in an introductory overview blog post that > also includes some links for further reading: > > http://www.humane-assessment.com/blog/gtdebugger-in-pharo/ > > Please let us know what you think. > > Cheers, > Doru > > > -- > www.tudorgirba.com > www.feenk.com > > "What is more important: To be happy, or to make happy?" > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev >

Jan. 8, 2016

Re: [Pharo-dev] What is the current status of flow (flow-stack)?

by Erik Stel

Hi Sebastian, Thanks for the update. I'm starting with a new project and need to get the requirements clear before deciding which tools will help me (and make me happy) most. I'll also continu using Meteor, but I prefer Smalltalk over Javascript/Coffeescript ;-). Currently I don't see Amber as the solution for replacing JS/CS within a Meteor solution. SqueakJS seems a 'heavy' solution since I probably would like to keep the front-end relatively thin (and not use the Morphic UI). Amber seems a better choice for that. But I'll investigate it too. Cheers! Erik -- View this message in context: http://forum.world.st/What-is-the-current-status-of-flow-flow-stack-tp48696… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 8, 2016

Setup Locale for Italy country

by Trussardi Dario Romano

Ciao, i work with Pharo4.0 Latest update: #40625 Now i need to setup the system to manage the Italy country - decimalSymbol ( , ) - currencySymbol ( â¬ ) -dateFormat dd-MM-yyyy HH:mm How i can do it ? What is the Pharo system status about localization ? The: Locale current answer aLocale instance with id set to it-It but with all variables set to nil. Thanks for any considerations, Dario

Jan. 8, 2016

gtdebugger in pharo 5.0

by Tudor Girba

Hi, We are about to integrate in Pharo a new member of the Glamorous Toolkit: the GTDebugger. As this is a significant change that might affect your workflow, here is some background information to help you deal with the change. First, you should know that the change is not irreversible and it is easily possible to disabled the new debugger through a setting. However, please do take the time to provide us feedback if something does not work out for you. We want to know what can be improved and we try to react as fast as we can. A practical change comes from the fact that the variables are manipulated through a GTInspector, which makes it cheaper to maintain in the longer run. While the first thing that will capture the attention is the default generic interface, the real power comes from the moldable nature of the debugger. Like all other GT tools, GTDebugger is also moldable by design. This means that we can construct custom debuggers for specific libraries at small costs (often measured in a couple of hundred lines of code). For example, the core configuration includes also the SUnit and the bytecode debugger. These are around 150 lines of code. Here is how the bytecode debugger looks like: You can find more information in an introductory overview blog post that also includes some links for further reading: http://www.humane-assessment.com/blog/gtdebugger-in-pharo/ Please let us know what you think. Cheers, Doru -- www.tudorgirba.com www.feenk.com "What is more important: To be happy, or to make happy?"

Jan. 8, 2016