April 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] SmallInteger #printString versus #printOn:

by Nicolas Cellier

Ah, but now that I've put a (selector == #unwindTo: and: [ self name = 'Context']) ifTrue:[self halt: 'debug me']. I can't reproduce the problem related to removal of Context methods!!! Instead, I've got the 'Merging Kernel-eem.1078' window with all the MethodContext->Context renaming in conflict I already reported that in another thread where I told that the upgrade went "smoothly" for both my 32 & 64 bits images. I don't know if it's related to package cache, or .mcd, or ??? It might also be that package ancestry is not correct du to overwriting of some packages, otherwise we should not get a merge window, but well... Ah, but now I think I understand: it's just because I have pending changes in Kernel due to the addition of halt: above (same for my images which usually have some unpublished experiments). We then trigger a merge rather than a load. And the merge sees conflict probably because of broken ancestry (the GUID are not corresponding), but once resolved manually, it processes smoothly without removing Context methods... I can't instrument code that easily... This will have to wait for another time slot :( 2017-04-08 13:41 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > > 2017-04-08 6:38 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > >> I was going to slip this example into the welcome help, >> >> 1 printString [debugIt] >> >> and I'm confronted by SmallInteger>>printString >> >> printString >> "Highly optimized version for base 10 >> and that we know it is a SmallInteger." >> | integer next result len | >> self = 0 ifTrue: [^'0']. >> self < 0 ifTrue: [^'-', self negated printString]. >> len := self decimalDigitLength. >> result := String new: len. >> integer := self. >> len to: 1 by: -1 do: [:i | >> next := integer // 10. >> result byteAt: i put: 48 + (integer - (next * 10)). >> integer := next]. >> ^result >> >> >> and I gather from other discussions this should(?) belong in >> SmallInteger>>printOn: >> Or is there a large benefit to avoiding the #printStringLimitedTo: >> machinery ? >> >> cheers -ben >> > > It should be printOn: generally, except that printOn: requires creating a > Stream, and requires passing thru Stream indirection for writing into the > target String. > > As the comment tells, the sole reason for this implementation is "Highly > optimized version". So consider that it's an exception to the rules. Maybe > this kind of decision could be periodically re-examined in the light of > performance measurements (I'm thinking of Sista)? >

April 8, 2017

Re: [Pharo-dev] SmallInteger #printString versus #printOn:

by Nicolas Cellier

2017-04-08 6:38 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > I was going to slip this example into the welcome help, > > 1 printString [debugIt] > > and I'm confronted by SmallInteger>>printString > > printString > "Highly optimized version for base 10 > and that we know it is a SmallInteger." > | integer next result len | > self = 0 ifTrue: [^'0']. > self < 0 ifTrue: [^'-', self negated printString]. > len := self decimalDigitLength. > result := String new: len. > integer := self. > len to: 1 by: -1 do: [:i | > next := integer // 10. > result byteAt: i put: 48 + (integer - (next * 10)). > integer := next]. > ^result > > > and I gather from other discussions this should(?) belong in > SmallInteger>>printOn: > Or is there a large benefit to avoiding the #printStringLimitedTo: > machinery ? > > cheers -ben > It should be printOn: generally, except that printOn: requires creating a Stream, and requires passing thru Stream indirection for writing into the target String. As the comment tells, the sole reason for this implementation is "Highly optimized version". So consider that it's an exception to the rules. Maybe this kind of decision could be periodically re-examined in the light of performance measurements (I'm thinking of Sista)?

April 8, 2017

Re: [Pharo-dev] stepping off the end of the debug stack

by Ben Coman

On Sat, Apr 8, 2017 at 12:32 PM, Ben Coman <btc(a)openinworld.com> wrote: > > I imagine a newcomer exploring the system could easily step off the end of > the debug stack like this... > > (1 printString) "debugIt" > then StepOver six times where the image hangs at "Processor > terminateActive" > > This could have a strong impact against first impressions. > What would it take to guard against this? > > cheers -ben > As an immediate stop-gap I'm adding the following comment to BlockClosure>>newProcess "IMPORTANT! Debug stepping this deep infrastructure may lock your Image" "If you are not sure what you are doing, close the debugger now." cheers -ben

April 8, 2017

SmallInteger #printString versus #printOn:

by Ben Coman

I was going to slip this example into the welcome help, 1 printString [debugIt] and I'm confronted by SmallInteger>>printString printString "Highly optimized version for base 10 and that we know it is a SmallInteger." | integer next result len | self = 0 ifTrue: [^'0']. self < 0 ifTrue: [^'-', self negated printString]. len := self decimalDigitLength. result := String new: len. integer := self. len to: 1 by: -1 do: [:i | next := integer // 10. result byteAt: i put: 48 + (integer - (next * 10)). integer := next]. ^result and I gather from other discussions this should(?) belong in SmallInteger>>printOn: Or is there a large benefit to avoiding the #printStringLimitedTo: machinery ? cheers -ben

April 8, 2017

stepping off the end of the debug stack

by Ben Coman

I imagine a newcomer exploring the system could easily step off the end of the debug stack like this... (1 printString) "debugIt" then StepOver six times where the image hangs at "Processor terminateActive" This could have a strong impact against first impressions. What would it take to guard against this? cheers -ben

April 8, 2017

books site description

by Ben Coman

Just a passing thought, at http://files.pharo.org/books/ it might be nice for the top descriptive text to indicate a reading order. Something like... Newcomers should start with Pharo By Example, then proceed to: - Spec UI Framework for desktop applications, - Enterprise Pharo for web development, - Agile Visualization for data processing. Deep Into Pharo and Numerical Methods are broadly applicable to all three domains. cheers -ben

April 8, 2017

Help currency review

by Ben Coman

At this late stage of Pharo 6 development, it might be good to do a pass at... World > Help > Help Browser content Epicea >Browsers - mentions two separate browser windows GT Debugger >> Actions - TODO GT Playground >> Overview - http://gt.moosetechnology.org redirects to http://gtoolkit.org/ and same for several GT entries Welcome > Getting Help says... - The "Pharo Users" mailing list: http://lists.pharo.org/mailman/listinfo/pharo-users_lists.pharo.org - The "Pharo Slack Team": http://slack4pharo.trentosur.com/ - The "Pharo IRC Channel": irc.freenode.net, #pharo channel - http://pharo.org/community So we should change from Slack to Discord. I can take care of this one but a couple questions... 1. I propose a Discord #Help channel to record here in the help browser. 2. I bumped into an interesting tip https://www.reddit.com/r/discordapp/comments/3yu1bh/server_vs_channel_invit… Thus I propose we have a #Welcome channel providing info like what the bot has been providing. Later it could be good to have a bot just in that channel, but not off someone's home server :) I would expect that channel to not need anyone lurking in it. Newcomers will jump immediately from there #Help or #General 3. How active is the IRC channel? Should we remove it from the help browser? The mention at http://pharo.org/community could be sufficient. 4. Should we backport this help info update to Pharo 5? cheers -ben

April 8, 2017

Enhanced GitHub code review

by Ben Coman

I bumped into this student dissertation. I only skimmed it quickly since its not a current interest of mine but I thought it might align with some members research interests. http://repository.tudelft.nl/islandora/object/uuid%3A52517b50-5da1-419a-b91… cheers -ben

April 8, 2017

[GT-Debugger] open an inspector on variable with the variable's name as its label?

by Bernardo Ezequiel Contreras

just an idea, what do you think if you open the inspector on a variable with the variable's name as its label when you are in the debugger's variables pane? when i open many inspectors, i get lost and i don't know what i was inspecting in the first place. -- Bernardo E.C. Sent from a cheap desktop computer in South America.

April 7, 2017

Re: [Pharo-dev] Tired of losing messages after 10k. Can we re-discuss moving Slack community to Discord?

by Yuriy Tymchuk

I have a grain of salt, because I have 4 other teams on Slack, so now I have to use 2 apps. But we have to move on, so letâs embrace the changes :). Uko > On 7 Apr 2017, at 19:32, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 7 Apr 2017, at 19:28, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >> >> I was disappointed that conversation didn't pick up in discord after the last announcement. > > it wasâ¦ but today is friday, people always talk less :) > > Esteban > >> >> cheers -ben >> >> P.S. >> I'm interested in playing with the discord API. >> https://discordapp.com/developers/docs/reference <https://discordapp.com/developers/docs/reference> >> but I can't get past the first step of OAuth authentication. >> https://discordapp.com/developers/docs/topics/oauth2 <https://discordapp.com/developers/docs/topics/oauth2> >> >> I tried a few weeks ago reading through several of the top Pharo OAuth search links, >> but it was beyond my ken and I got discouraged. Perhaps some kind soul >> with past OAuth experience would find it easier to crack and open the door >> for others to work on the remaining API. >> >> Perhaps we could do something similar to the Google API Service Discovery tool >> https://www.min.at/prinz/?x=entry:entry150318-104537 <https://www.min.at/prinz/?x=entry:entry150318-104537> >> >> I got a list of endpoints >> https://gist.github.com/SinisterRectus/9518f3e7d0d1ccb4335b2a0d389c30b0 <https://gist.github.com/SinisterRectus/9518f3e7d0d1ccb4335b2a0d389c30b0> >> from the API chat channel >> https://discordapp.com/invite/discord-api <https://discordapp.com/invite/discord-api> >> >> It would be cool to have a chat channel inside a Pharo Image that could >> understand dropped Class>>method links. Also a group voice channel from within >> Pharo might be a good adjunct to a game engine like Ronnie is developing. >> >> more cheers -ben >> >> On Sat, Apr 8, 2017 at 12:25 AM, Dimitris Chloupis <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: >> That's the solution Unreal followed , they were on Slack , the shut it down and left a message. >> >> Moving to Discord is super easy and it literally takes a minute. We can leave an invite link to the closed Slack and that's it. >> There is no need to wait for a planatery alignment or GSOC. It's far more complicated to setup ah fogbuz account for reporting Pharo bugs. There is also nothing new to learn for its usage. I also have a custom made bot made in Python which we can customize to accommodate for specific needs. >> >> >> On Fri, 7 Apr 2017 at 16:00, Esteban A. Maringolo <emaringolo(a)gmail.com <mailto:emaringolo@gmail.com>> wrote: >> We could shut down Slack team or leave a sticky note in the general >> channel saying that we moved everything to Discord. >> >> Regards! >> >> >> Esteban A. Maringolo >> >> >> 2017-04-07 9:39 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>>: >> > I would not mind moving to Discord. But, what is the plan to kill Slack? Can >> > a Slack project be simply removed? >> > >> > Alexandre >> > -- >> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> > >> > >> > On Apr 7, 2017, at 8:59 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> > >> > Hi, >> > >> > That. >> > Iâm also willing to try another service if you find something better, but I >> > find discord cool enough. >> > Some remarks: >> > >> > - I actually like Slack. The problem is the amount of information lost >> > because they do not display more than 10k lines (or we pay, and is super >> > expensive). >> > - No, plain #irc is not an option. Community has talkedâ¦ and it does not >> > worksâ¦ I have had more productive talks in one month in Slack than 5 years >> > trying #irc. >> > >> > cheers! >> > Esteban >> > >> > >> > >> >> >

April 7, 2017