January 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] PNG in Artefact

by Stephan Eggermont

Olivier wrote: >In fact, the PNG is converted to JPEG image before to be included in the PDF file. >But the conversion process doesn't support transparency and sets a black background. Jpeg doesn't have transparency. For browsers there is a hack. http://jim.studt.net/jpeg-alpha/ http://stackoverflow.com/questions/14220221/how-to-insert-transparent-png-i… PDF supports transparency since PDF 1.4 To avoid trouble, only use images with the same color space and either a 1 bit mask or a clipping path. Composing images in different color spaces with an alpha channel seems to be difficult to get right. Stephan

Jan. 12, 2015

Re: [Pharo-dev] R: from 2009's The "death" of Smalltalk to 2014's But Really, You Should Learn Smalltalk

by Sven Van Caekenberghe

> On 12 Jan 2015, at 09:15, Lorenzo Schiavina <lorenzo(a)edor.it> wrote: > > Hi, > > instead of using the trivial 2 + 2 as ST example, for many years I have found more impressive: 50000 factorial printString size and then to show factorial method, that is very easy to understand. > IMHO it is STâs essence of innovation and power. What about showing/explaining (progressive complexity) 123 factorial. 123 factorial numberOfDigits. 123 factorial primeFactors. 123 factorial primeFactors reduce: [ :x :y | x * y ]. And in the last inspector self = 123 factorial The video was pretty good, but I would never start discussing precedence rules in this type of presentation and certainly not using plain arithmetic. > > Lorenzo > > Da: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Per conto di Sebastian Sastre > Inviato: venerdÃ¬ 9 gennaio 2015 19:07 > A: Pharo Development List > Oggetto: Re: [Pharo-dev] from 2009's The "death" of Smalltalk to 2014's But Really, You Should Learn Smalltalk > > Hi Jochen, > > have in mind that the talk you referred is from 2009 and many controversial things happened in the Ruby community at that time. > > Coming closer to today, we just had this presentation which presents Smalltalk better than many Smalltalkers Iâve heard! > https://www.youtube.com/watch?v=eGaKZBr0ga4 > > Want to show off smalltalk to non-smalltalker audiences in an effective way? watch and learn! > > > > >> On Jan 9, 2015, at 3:37 PM, J.F. Rick <self(a)je77.com> wrote: >> >> Hi everyone, >> >> I just watched https://www.youtube.com/watch?v=YX3iRjKj7C0 and had a few comments that I thought I would share. >> >> First, there is a real opportunity for Smalltalk to come back in the guise of Pharo. Steph and Marcus are doing a great job providing leadership towards that end and the community is great. Second, we need to be careful in spreading the word. Slowly but surely (the current Pharo approach) is a great approach as it allows really building something worth spreading before trying to get everyone into it. If it spreads too quickly, bad API or immature toolkits will become ingrained and flaws will be apparent. The books, websites, etc. are really good things to get right before trying to get others into it; they are already very good. Third, if you want to really spread Smalltalk, then the fundamentals that newcomers experience need to be without obvious flaws. From personal experience, I can tell you that BitBlt rendering makes newbies think that Pharo is a toy language. Switching to Athens rendering is therefore tremendously important for adoption. Package management really needs to be cleaned up. There needs to be a simple way to merge resources (bitmaps, audio, external files) into the codebase. Simple audio needs to work on all platforms. This may seem trivial but audio is one of the simplest things that newcomers want to do. From a Linux perspective, this will probably necessitate switching to a 64-bit VM as the 32-bit sound plug-ins are a giant pain. Given that even phone OSs are switching to 64-bit, there may not be a need for a 32-bit Pharo. Of course, much of this is already on the horizon. >> >> As the new year begins, I'll once again be coding in Pharo and look forward to it. I'm really hopeful about the future. >> >> Cheers, >> >> Jeff >> >> -- >> Jochen "Jeff" Rick, Ph.D. >> http://www.je77.com/ >> Skype ID: jochenrick

Jan. 12, 2015

R: from 2009's The "death" of Smalltalk to 2014's But Really, You Should Learn Smalltalk

by Lorenzo Schiavina

Hi, instead of using the trivial 2 + 2 as ST example, for many years I have found more impressive: 50000 factorial printString size and then to show factorial method, that is very easy to understand. IMHO it is STÂs essence of innovation and power. Lorenzo Da: Pharo-dev [ <mailto:pharo-dev-bounces@lists.pharo.org> mailto:pharo-dev-bounces@lists.pharo.org] Per conto di Sebastian Sastre Inviato: venerdÃ¬ 9 gennaio 2015 19:07 A: Pharo Development List Oggetto: Re: [Pharo-dev] from 2009's The "death" of Smalltalk to 2014's But Really, You Should Learn Smalltalk Hi Jochen, have in mind that the talk you referred is from 2009 and many controversial things happened in the Ruby community at that time. Coming closer to today, we just had this presentation which presents Smalltalk better than many Smalltalkers IÂve heard! <https://www.youtube.com/watch?v=eGaKZBr0ga4> https://www.youtube.com/watch?v=eGaKZBr0ga4 Want to show off smalltalk to non-smalltalker audiences in an effective way? watch and learn! On Jan 9, 2015, at 3:37 PM, J.F. Rick < <mailto:self@je77.com> self(a)je77.com> wrote: Hi everyone, I just watched <https://www.youtube.com/watch?v=YX3iRjKj7C0> https://www.youtube.com/watch?v=YX3iRjKj7C0 and had a few comments that I thought I would share. First, there is a real opportunity for Smalltalk to come back in the guise of Pharo. Steph and Marcus are doing a great job providing leadership towards that end and the community is great. Second, we need to be careful in spreading the word. Slowly but surely (the current Pharo approach) is a great approach as it allows really building something worth spreading before trying to get everyone into it. If it spreads too quickly, bad API or immature toolkits will become ingrained and flaws will be apparent. The books, websites, etc. are really good things to get right before trying to get others into it; they are already very good. Third, if you want to really spread Smalltalk, then the fundamentals that newcomers experience need to be without obvious flaws. From personal experience, I can tell you that BitBlt rendering makes newbies think that Pharo is a toy language. Switching to Athens rendering is therefore tremendously important for adoption. Package management really needs to be cleaned up. There needs to be a simple way to merge resources (bitmaps, audio, external files) into the codebase. Simple audio needs to work on all platforms. This may seem trivial but audio is one of the simplest things that newcomers want to do. From a Linux perspective, this will probably necessitate switching to a 64-bit VM as the 32-bit sound plug-ins are a giant pain. Given that even phone OSs are switching to 64-bit, there may not be a need for a 32-bit Pharo. Of course, much of this is already on the horizon. As the new year begins, I'll once again be coding in Pharo and look forward to it. I'm really hopeful about the future. Cheers, Jeff -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Jan. 12, 2015

Re: [Pharo-dev] GT tool request

by Tudor Girba

Hi Stef, Thanks a lot for the detailed report. Comments inline. On Sun, Jan 11, 2015 at 9:11 PM, stepharo <stepharo(a)free.fr> wrote: > Hi > > I found the blue rectangle morph painful because it blocks me when I want > to freely edit expression and result. > Would it be possible that when I type enter the blue rectangle text is > paste in the pane below its expression. > We are debating this feature since quite a while and we indeed need to settle on a solution. Esteban also wanted Enter, and I was more inclined towards Cmd+v. I opened an issue: https://pharo.fogbugz.com/f/cases/14711/The-Playground-print-popper-should-… Right now I have to copy and paste explictly and it not working. I hate so > much this broken interaction.... > Indeed. The main use case considered for the popper (that is the name of the widget) is to not get the original editor dirty. The current way to do things is like this: - Cmd+c - Esc - Right Arrow - Cmd+v Clearly not ideal. Example > > (20@200) printString get blue rectangle > press copy parentheses got hilighlited no idea why > There are two things here, and this is confusing right now in the Pharo theme: The background of the popper has the same background as the text selection: https://pharo.fogbugz.com/f/cases/14712/The-print-popper-should-have-a-diff… The reason you see the parantheses selected is due to the smart parantheses mechanism that I did not know how to suppress only for one text widget :(. > then I press enter to go to the next line (my selection vanished of course > because the magic things selected everything automatically) > The selection is the same as in the previous interface. For example, in a basic Workspace, press Cmd+i without selecting anything and the whole like will be selected. We cannot just erase the selection when we exit the popper because sometimes you actually have an explicit selection that you should not lose. But, coming to think about it, we should probably use the highlighting mechanism for the text instead of the selection one. I will look into this. > and I can paste the result and start to edit it. I sincerly hope that GT guys will understand and modify it because right > now this is a show stopper to me. > It breaks so badly interaction with texts. > We will fix this, but in the meantime, could you tell me the use case for which you need to paste the text in the same editor? I am asking because I would like to learn as I never need to do it. This is why the interface does not support that action so I need to learn the use case :). Cheers, Doru > Stef > > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 12, 2015

Re: [Pharo-dev] [Pharo4] Slots can now be saved with MC

by Ben Coman

@Chris, That sounds like a balance response. Its also been a while since I read it, and probably time I read it again and to have a play with slots (although last I heard it wasn't ready for prime time to do everything in the paper.) While the cognitive load might go up, I don't think its necessarily exponential. They way I think about it (blurred since I last read the paper) is that the assignment operator sort-of becomes a message send that you can redefine, and the slots are like mini-classes with limited scope - so there is a reuse of concepts. The complexity for grandma will all come down to the discoverability build into the tools - like how debugging interacts with slots. I don't think (and hope) it won't be much harder than learning to work with both an instance & class-side, and the difference between instance, class, class-instance and pool variables. On Mon, Jan 12, 2015 at 5:50 AM, Chris Muller <asqueaker(a)gmail.com> wrote: > It has been a while since I read the paper, but my memory is that > Slots lets you define features and/or constraints on inst-var's. For > example, assigning default values or restricting the set of valid > values. > > This would probably be appealing for folks coming from languages like > Java or C++, because they're used to all of their "slots" being > statically typed. It does seem ironic that where those static > languages have been trying to move toward being more dynamic, Pharo > newbies would find themselves arrived at a language which is trying to > make something that was purely dynamic into something more static. > > My understanding is that specifying a certain Slot-type can save the > need to write, i.e., initializing or validating methods. In exchange, > the number of concepts inherent in the language that must be learned > and remembered is increased. Standard Smalltalk is only about 2 or 3 > concepts -- sending messages and assigning pointers. Period. There's > something exciting about that because even Grandma can grok 2 or 3 > concepts. No other language is so simple. > > By introducing the implicit behaviors of slots, the number of > different conceptual interactions between code and the slots it > references increases exponentially with the number of slot-types. I > fear trying to explain them to Grandma will have her eyes starting to > glaze... > > PS -- I hope no one would characterize me as "violently" against > slots. It may simply be my own ignorance.. > > On Fri, Jan 9, 2015 at 1:50 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > > > > > On Fri, Jan 9, 2015 at 11:47 AM, Marcus Denker <marcus.denker(a)inria.fr> > > wrote: > >> > >> > >> > On 09 Jan 2015, at 16:45, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> > > >> > Hi Marcus, > >> > > >> > > >> > P.S. Maybe now Slots are ready for stealing by Squeak ;-) > >> > >> Everything I ever did for Pharo I wanted to do for Squeakâ¦ but I could > not > >> because > >> someone was violently against it. > > > > > > We will heal. It may take a long time, but we will. And things are > going > > great right now, especially for Pharo. So I hope that your pain will > ease > > and that one day you will be free of it. Hugs, and happy new year. And > > thanks for Slots and Opal and all the other wonderful things you do. > > > >> Marcus > >> > >> > > > > > > > > -- > > best, > > Eliot > >

Jan. 11, 2015

Re: [Pharo-dev] [squeak-dev] OSProcess stdErr issue on Windows

by Thierry Goubier

2015-01-11 20:42 GMT+01:00 David T. Lewis <lewis(a)mail.msen.com>: > Thanks Ben, > > > I copied ConfigurationOfOSProcess-ThierryGoubier.33 to the OSProcess > repository. An update to ConfigurationOfOSProcess will be needed to > get the latest version (Thierry, can you do this?). > Yes, I will. Thierry > > For Squeak, no ConfigurationOfOSProcess is needed, just use the latest > version (with SqueakMap, or currently it OSProcess-dtl.93 in the repo). > > Pharo should also use the latest version if possible, although the > Metacello configurations are needed to make things work on various older > Pharo versions. The versions for a current spec would be: > > OSProcess-Base-dtl.46 > OSProcess-Unix-dtl.20 > OSProcess-Win32-dtl.12 > OSProcess-Mac-dtl.2 > OSProcess-OS2-dtl.2 > OSProcess-RiscOS-dtl.2 > OSProcess-AIO-dtl.8 > Tests-OSProcess-dtl.21 > > > > > cheers -ben > > > > [1] https://pharo.fogbugz.com/default.asp?11615 > > Thanks a lot for reporting this! > > Dave > > >

Jan. 11, 2015

Re: [Pharo-dev] [squeak-dev] OSProcess stdErr issue on Windows

by Ben Coman

Thanks Dave. I'll try it out this evening. cheers -ben On Mon, Jan 12, 2015 at 4:21 AM, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Sun, Jan 11, 2015 at 03:07:59PM -0500, David T. Lewis wrote: > > On Sun, Jan 11, 2015 at 02:42:01PM -0500, David T. Lewis wrote: > > > > > > I copied ConfigurationOfOSProcess-ThierryGoubier.33 to the OSProcess > > > repository. An update to ConfigurationOfOSProcess will be needed to > > > get the latest version (Thierry, can you do this?). > > > > > > For Squeak, no ConfigurationOfOSProcess is needed, just use the latest > > > version (with SqueakMap, or currently it OSProcess-dtl.93 in the repo). > > > > > > Pharo should also use the latest version if possible, although the > > > Metacello configurations are needed to make things work on various > older > > > Pharo versions. The versions for a current spec would be: > > > > > > OSProcess-Base-dtl.46 > > > OSProcess-Unix-dtl.20 > > > OSProcess-Win32-dtl.12 > > > OSProcess-Mac-dtl.2 > > > OSProcess-OS2-dtl.2 > > > OSProcess-RiscOS-dtl.2 > > > OSProcess-AIO-dtl.8 > > > Tests-OSProcess-dtl.21 > > > > > > > Oops, sorry. That should be OSProcess-Tests-dtl.12, not > Tests-OSProcess-dtl.21. > > Sorry to keep replying to myself, but I noticed some missing test updates > from > the main OSProcess package, so now it is OSProcess-Tests-dtl.13. > > Dave > > >

Jan. 11, 2015

Re: [Pharo-dev] [Pharo4] Slots can now be saved with MC

by Chris Muller

It has been a while since I read the paper, but my memory is that Slots lets you define features and/or constraints on inst-var's. For example, assigning default values or restricting the set of valid values. This would probably be appealing for folks coming from languages like Java or C++, because they're used to all of their "slots" being statically typed. It does seem ironic that where those static languages have been trying to move toward being more dynamic, Pharo newbies would find themselves arrived at a language which is trying to make something that was purely dynamic into something more static. My understanding is that specifying a certain Slot-type can save the need to write, i.e., initializing or validating methods. In exchange, the number of concepts inherent in the language that must be learned and remembered is increased. Standard Smalltalk is only about 2 or 3 concepts -- sending messages and assigning pointers. Period. There's something exciting about that because even Grandma can grok 2 or 3 concepts. No other language is so simple. By introducing the implicit behaviors of slots, the number of different conceptual interactions between code and the slots it references increases exponentially with the number of slot-types. I fear trying to explain them to Grandma will have her eyes starting to glaze... PS -- I hope no one would characterize me as "violently" against slots. It may simply be my own ignorance.. On Fri, Jan 9, 2015 at 1:50 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Fri, Jan 9, 2015 at 11:47 AM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: >> >> >> > On 09 Jan 2015, at 16:45, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > >> > Hi Marcus, >> > >> > >> > P.S. Maybe now Slots are ready for stealing by Squeak ;-) >> >> Everything I ever did for Pharo I wanted to do for Squeakâ¦ but I could not >> because >> someone was violently against it. > > > We will heal. It may take a long time, but we will. And things are going > great right now, especially for Pharo. So I hope that your pain will ease > and that one day you will be free of it. Hugs, and happy new year. And > thanks for Slots and Opal and all the other wonderful things you do. > >> Marcus >> >> > > > > -- > best, > Eliot

Jan. 11, 2015

athens font rendering and subpixel antialiasing

by Nicolai Hess

Anyone knows, why the text rendering with athens (cairo) looks slightly different than the freetypeplugin one? attached is a screenshot, left side athen right side (morphic) freetypeplugin. It "looks" like the cairo freetype fontrendering uses CAIRO_ANTIALIAS_GRAY, no colored subpixel antialiasing. But the font options do define antialiase subpixel and a subpixel ordering RGB. This is on windows 7 with the latest vm, does it look different on other Systems? nicolai

Jan. 11, 2015

Re: [Pharo-dev] PNG in Artefact

by stepharo

olivier the problem with transparency is that it often depends on the printer driver (no joke) I once asked the people from omingraffle and they told me that there is no standard. Stef Le 11/1/15 21:23, olivier auverlot a Ã©crit : > In fact, the PNG is converted to JPEG image before to be included in > the PDF file. But the conversion process doesn't support transparency > and sets a black background. I think that is a limitation in the JPEG > writer but someone have perhaps an idea to fix it. > > Olivier ;-) > > 2015-01-11 21:11 GMT+01:00 Torsten Bergmann <astares(a)gmx.de > <mailto:astares@gmx.de>>: > > > JPEG supports is degrading. Less and less good support. > > > > Le 11/1/15 18:04, Torsten Bergmann a Ã©crit : > > >>> I improved Artefact this morning and added the support for > PNG files. It's now possible to use PDFPngElement to include a PNG > (untransparent) in a PDF file produced by Artefact. > > > Nice, what is the reason only untransparent PNGs work? > > Thanks - but that was not my question. PNG graphics format can - > but must not > include transparency. When I understand the mail correct only > non-transparent > PNG images are supported with the new addition. > > That's why I ask about transparent PNG. > > Bye > T. > >

Jan. 11, 2015