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

Re: [Pharo-dev] discord channel request

by Dimitris Chloupis

"I like the idea. What is necessary to make it work? Can you describe a bit more in detail the use case and required infrastructure? Do we have any code I could reuse?" Hey there , Discord has a web API that can be found here https://discordapp.com/developers/docs/intro There are wrappers of the API for several languages, I use wrappers for Python that can be found here https://github.com/Rapptz/discord.py to make a bot that can be found https://github.com/kilon/lighthouse A bot is basically a bit like a client because a bot has to get info about the messages , the members etc. You can use my Atlas project to use the python discord api from inside pharo, this way you avoid a full rewrite of a wrapper and you have access to a ton of python code, including my bot "There have been some requests to remove the bot. But I see that you've responded to feedback to tune its behaviour, so I'm happy to wait to see how that panes out. But oh! the irony... jecisc-Yesterday at 8:16 PM Can you delete this level thing with the bot please?(edited) Mee6BOT-Yesterday at 8:16 PM GG @jecisc, you just advanced to level 3 !" Mee6 is the name of the bot, its one of the most popular for Discord. I have it temporary , my bot which called Lighthouse can completely replace it at some point I am just waiting to see the needs of the community and of course the time I can invest on this. I started it the bot because Esteban wanted to move to Discord then I gave up on it because it was clear people wanted to stick with Slack. Then Esteban brought the subject of a complete migration to Discord so I am on standby to improve the bot if people start joining in. The level thing message was indeed annoying . "Its not just about searchability. Its a social barrier thing. If the regulars are rolling through some deep discussion, a newcomer may hesitate to jump in with a side topic. If you want to condense channels, then probably the #mooc and #help could be rolled into one. cheers -ben" I want beginners to feel comfortable with experienced Pharo coders , I do not want to accommodate their fears and insecurities. Many people when they join a community they feel like outsiders fools that waste other people's time. Its important to make them see we are one big family that see beyond experience and we all just here because we love Pharo and not because we have something to prove. For me this extremely crucial , facing this fear and stereotype, thus I am not in favor of any kind of "help" channel, mailing lists etc. BUT in the end I am not a dictator I am just here to help the community , if the community wants a #help channel that is what it will get but again I will need an #admin that will be there to help the newcomers and preferably more than one. I want admis on each channel because in the end it needs the cooperation of many to create a great community. For me admin is a lot more about making people feel comfortable than deleting posts and banning people. By the way you are already an admin for all channels , you can create new ones if you want. You do not need my permission to do so. Anyone who is serious about helping out and wants to become admin, join and drop me a message.

April 9, 2017

Re: [Pharo-dev] discord channel request

by Ben Coman

On Sun, Apr 9, 2017 at 8:09 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > #welcome is not necessary there is already a bot in place that provides a > welcome message and displays a command for help for newcomers There have been some requests to remove the bot. But I see that you've responded to feedback to tune its behaviour, so I'm happy to wait to see how that panes out. But oh! the irony... jecisc-Yesterday at 8:16 PM Can you delete this level thing with the bot please?(edited) Mee6BOT-Yesterday at 8:16 PM GG @jecisc, you just advanced to level 3 ! btw, where is the bot hosted? > #help is not necessary too, Discord has a search capability which could be > potentially used from inside a Pharo image but again the question is who is > going to do this Its not just about searchability. Its a social barrier thing. If the regulars are rolling through some deep discussion, a newcomer may hesitate to jump in with a side topic. If you want to condense channels, then probably the #mooc and #help could be rolled into one. cheers -ben > > #mooc , I am not against this idea but again we had a student yesterday > asking for help that is following Mooc , I had no problem providing it and > he had not issues with the process of getting his question aswered in > #general channel. If he asked at #mooc I would have missed it because I am > not going to keep a mind in all channels. > > For general questions I would prefer , even if they are mooc related , to be > at #general channel, lets not fragment our discussions for little > justification, > but for very mooc discusions, like where to find a specific > teach or reports of errors in mooc it makes sense to have a mooc channel. > > My policy is to point an admin for each channel , channel admis are > different than us general admins, we have full power they can only > > 1)manage message in a specific channel > 2) manage webhooks (for example github commits or rss feeds) > 3) create instant invites > > so if there is one person that is willing to become a mooc admin i will > create the channel and add his as admin > > On Sun, Apr 9, 2017 at 5:33 AM Ben Coman <btc(a)openinworld.com> wrote: >> >> Could we have additional channels: >> >> #welcome - which would be the generally advertised invite URL. A >> read-only channel that informs about community rules and summaries available >> channels etc (maybe including hidden channels and who to ask for invite) >> >> #help - To be referenced from in-Image Help Browser. Maybe later have an >> in-Image chat tool that connects to this channel. How cool would it be to >> have live help from within the IDE? >> >> #mooc - So people can maybe look back through history before asking >> questions, and also people further along might help others less advanced ==> >> more participation >> >> cheers -ben

April 9, 2017

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

by Eliot Miranda

Hi Ben, hmmm, good thought. Seems to me that the right solution is in the primitive simulations in Context>>tryPrimitive... or Context>>doPrimitive... (*) so that the debugger process isn't terminated, but the process being debugged is. (* at my phone right now so don't have the code to look at to answer the correct selectors) _,,,^..^,,,_ (phone) > On Apr 8, 2017, at 7:23 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2017-04-08 6:46 GMT+02:00 Ben Coman <btc(a)openinworld.com>: >> >> >>> 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 > > > +1 >

April 9, 2017

Re: [Pharo-dev] discord channel request

by Juraj Kubelka

Hi, > El 09-04-2017, a las 09:09, Dimitris Chloupis <kilon.alios(a)gmail.com> escribiÃ³: > > #welcome is not necessary there is already a bot in place that provides a welcome message and displays a command for help for newcomers > > #help is not necessary too, Discord has a search capability which could be potentially used from inside a Pharo image but again the question is who is going to do this I like the idea. What is necessary to make it work? Can you describe a bit more in detail the use case and required infrastructure? Do we have any code I could reuse? Juraj > > #mooc , I am not against this idea but again we had a student yesterday asking for help that is following Mooc , I had no problem providing it and he had not issues with the process of getting his question aswered in #general channel. If he asked at #mooc I would have missed it because I am not going to keep a mind in all channels. > > For general questions I would prefer , even if they are mooc related , to be at #general channel, lets not fragment our discussions for little justification, but for very mooc discusions, like where to find a specific teach or reports of errors in mooc it makes sense to have a mooc channel. > > My policy is to point an admin for each channel , channel admis are diffirent than us general admins, we have full power they can only > > 1)manage message in a specific channel > 2) manage webhooks (for example github commits or rss feeds) > 3) create instant invites > > so if there is one person that is willing to become a mooc admin i will create the channel and add his as admin > >> On Sun, Apr 9, 2017 at 5:33 AM Ben Coman <btc(a)openinworld.com> wrote: >> Could we have additional channels: >> >> #welcome - which would be the generally advertised invite URL. A read-only channel that informs about community rules and summaries available channels etc (maybe including hidden channels and who to ask for invite) >> >> #help - To be referenced from in-Image Help Browser. Maybe later have an in-Image chat tool that connects to this channel. How cool would it be to have live help from within the IDE? >> >> #mooc - So people can maybe look back through history before asking questions, and also people further along might help others less advanced ==> more participation >> >> cheers -ben

April 9, 2017

Re: [Pharo-dev] discord channel request

by Dimitris Chloupis

#welcome is not necessary there is already a bot in place that provides a welcome message and displays a command for help for newcomers #help is not necessary too, Discord has a search capability which could be potentially used from inside a Pharo image but again the question is who is going to do this #mooc , I am not against this idea but again we had a student yesterday asking for help that is following Mooc , I had no problem providing it and he had not issues with the process of getting his question aswered in #general channel. If he asked at #mooc I would have missed it because I am not going to keep a mind in all channels. For general questions I would prefer , even if they are mooc related , to be at #general channel, lets not fragment our discussions for little justification, but for very mooc discusions, like where to find a specific teach or reports of errors in mooc it makes sense to have a mooc channel. My policy is to point an admin for each channel , channel admis are diffirent than us general admins, we have full power they can only 1)manage message in a specific channel 2) manage webhooks (for example github commits or rss feeds) 3) create instant invites so if there is one person that is willing to become a mooc admin i will create the channel and add his as admin On Sun, Apr 9, 2017 at 5:33 AM Ben Coman <btc(a)openinworld.com> wrote: > Could we have additional channels: > > #welcome - which would be the generally advertised invite URL. A > read-only channel that informs about community rules and summaries > available channels etc (maybe including hidden channels and who to ask for > invite) > > #help - To be referenced from in-Image Help Browser. Maybe later have an > in-Image chat tool that connects to this channel. How cool would it be to > have live help from within the IDE? > > #mooc - So people can maybe look back through history before asking > questions, and also people further along might help others less advanced > ==> more participation > > cheers -ben >

April 9, 2017

discord channel request

by Ben Coman

Could we have additional channels: #welcome - which would be the generally advertised invite URL. A read-only channel that informs about community rules and summaries available channels etc (maybe including hidden channels and who to ask for invite) #help - To be referenced from in-Image Help Browser. Maybe later have an in-Image chat tool that connects to this channel. How cool would it be to have live help from within the IDE? #mooc - So people can maybe look back through history before asking questions, and also people further along might help others less advanced ==> more participation cheers -ben

April 9, 2017

VM flavour for Pharo 6 release

by Ben Coman

Hi Esteban, What flavour of VM is going to be in Pharo 6 release? Do you think a move to the thread-beat one is a feasible? On Case 19820 "Epicea: GrafPort error when open browser" [1] I see the comment "These are two different VM versions. In both I have sometimes this crash, sometimes another crashes. The threaded VM version seems to be working (it's what I'm using now), but with the itimer ones I started to have this crashes." and I guess the thread-beat is more robust in interaction with third-party FFI signal handling. Should we particularly encourage everyone to update to latest thread-beat VM to provide additional testing before release? cheers -ben [1] https://pharo.fogbugz.com/f/cases/19820

April 9, 2017

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

by Nicolai Hess

2017-04-08 6:46 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > > > 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 > +1

April 8, 2017

Software maintenance costs in the real world (Re: ftp repositories broken)

by David T. Lewis

For students of software engineering, I offer this as an example of one of the most common and costly types of error that you will encounter in real life. A small error may be introduced early in the development process, possibly slipping through the cracks through lack of review (as was the case in this example). The change is motivated by good intentions, but some aspect of the overall system design is overlooked. Once the mistake has been made, it becomes increasingly difficult to change as time goes by, and increasingly costly to support as new people need to understand the issue and work around its consequences. Over the life of the software, the accumulated costs of effort to understand and address the problem (typically budgeted separately under "software maintenance") far exceed the costs associated with the original change (typically budgeted as "development"). In addition to cost of maintenance, this kind of error can also defeat the intentions of the original developer. In the example we have here, the original change was motivated by an interest in making the system cleaner and easier to understand. But nearly a decade later, we see workarounds such as the #translatedPrimitives method below that are far worse than the original problem that someone was trying to solve. For the historical background on this particular exammple, see the earlier post by Henrik Sperre Johansen in this thread. Dave p.s. I am not a software engineer :-) On Tue, Apr 04, 2017 at 06:45:27PM +0200, Esteban Lorenzano wrote: > > > On 4 Apr 2017, at 18:01, Ben Coman <btc(a)openInWorld.com> wrote: > > > > > > > > On Tue, Apr 4, 2017 at 10:12 PM, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > > > > > > > > > 2017-04-04 15:47 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > > >> > > >> no it doesn't: squeak does not have that primitive, that???s why it does not fails :) > > > > > > > > > I think you are wrong because I check it carefully in Squeak and I found it on github https://github.com/OpenSmalltalk/opensmalltalk-vm/search?utf8=???&q=primiti… <https://github.com/OpenSmalltalk/opensmalltalk-vm/search?utf8=%E2%9C%93&q=p…>. > > still is not there, because is not the same primitive :) > look, this is the way where it is generated: > > translatedPrimitives > "an assorted list of various primitives" > (ByteString compiledMethodAt: #findSubstringViaPrimitive:in:startingAt:matchTable: ifAbsent: []) ifNotNil: > [^#("Pharo uses findSubstringViaPrimitive:in:startingAt:matchTable:" > (Bitmap compress:toByteArray:) > (Bitmap decompress:fromByteArray:at:) > (Bitmap encodeBytesOf:in:at:) > (Bitmap encodeInt:in:at:) > (ByteString compare:with:collated:) > (ByteString translate:from:to:table:) > (ByteString findFirstInString:inSet:startingAt:) > (ByteString indexOfAscii:inString:startingAt:) > (String findSubstringViaPrimitive:in:startingAt:matchTable:) > (ByteArray hashBytes:startingWith:) > (SampledSound convert8bitSignedFrom:to16Bit:))]. > ^#( > (Bitmap compress:toByteArray:) > (Bitmap decompress:fromByteArray:at:) > (Bitmap encodeBytesOf:in:at:) > (Bitmap encodeInt:in:at:) > (ByteString compare:with:collated:) > (ByteString translate:from:to:table:) > (ByteString findFirstInString:inSet:startingAt:) > (ByteString indexOfAscii:inString:startingAt:) > (ByteString findSubstring:in:startingAt:matchTable:) > (ByteArray hashBytes:startingWith:) > (SampledSound convert8bitSignedFrom:to16Bit:) > ) > > means that Pharo uses #indSubstringViaPrimitive:in:startingAt:matchTable: while squeak uses #findSubstring:in:startingAt:matchTable:. > Now, there is a bug there (because source is in String and not in ByteString), and I can fix that by asking correctly, but: > > 1) this means that sources for pharo and squeak will be different and pharo needs to be generated in pharo. This is contrary to what we are trying to do with the VM: we want all sources to be the same, and differences should come from compilation flags and/or the presence of certain plugins (this is because is a lot easier to debug the VM like that). > 2) I wonder??? why we are using this primitive an squeak is not? maybe we need to deprecate the use? > > > I believe Esteban's point Its not so much whether the VM has it > > (since they are essentially the same VM + extra C-libs for Pharo) > > but whether the Squeak Image is using it. > > > > Squeak does use primitiveFindSubstring, but a difference is attached to ByteString rather than String. > > That was added to Squeak 2015.05.01. Squeak String seems to have never used the primitive (since 2005). > > this is the important thing, I think??? so??? why can???t we use that instead the other one? > what???s the difference? > > cheers! > Esteban > > > > > > A diff shows some differences in implementation.. > > https://www.diffchecker.com/CmBJZjB6 <https://www.diffchecker.com/CmBJZjB6> > > which anyway wouldn't account for John's observations. > > > > cheers -ben >

April 8, 2017

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

by Nicolas Cellier

Hmm forget about this, wrong thread... 2017-04-08 13:58 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > 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@ > 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