- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] How to set styler for RubEditingArea?

by Stephan Eggermont

On 19-03-16 10:59, Henrik Nergaard wrote: > There is no way of doing that, RubParagraphDecorator lacks a method to set its style variable. > > If you add that, then you can do something like: > Self is a RubEditingArea > > (self decoratorNamed: #shoutStyler) style: yourStyleclass new. > I'm strongly in favor of adding this. There are other languages I want to style than smalltalk. Stephan

March 19, 2016

Re: [Pharo-dev] How to set styler for RubEditingArea?

by Henrik Nergaard

Correction, I forgot some r's.... There is no way of doing that, RubParagraphDecorator lacks a method to set its styler variable. If you add that, then you can do something like: Self is a RubEditingArea (self decoratorNamed: #shoutStyler) styler: yourStyleclass new. styler: aTextStyler styler := aTextStyler. styler view: self. Best regards, Henrik -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Henrik Nergaard Sent: Saturday, March 19, 2016 11:00 AM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] How to set styler for RubEditingArea? There is no way of doing that, RubParagraphDecorator lacks a method to set its style variable. If you add that, then you can do something like: Self is a RubEditingArea (self decoratorNamed: #shoutStyler) style: yourStyleclass new. Best regards, Henrik -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Yuriy Tymchuk Sent: Saturday, March 19, 2016 1:19 AM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: [Pharo-dev] How to set styler for RubEditingArea? Hi, I have my own styler which is a subclass of SHRBTextStyler. How do I set it as a styler for RubEditingArea? Cheers. Uko

March 19, 2016

Re: [Pharo-dev] How to set styler for RubEditingArea?

by Henrik Nergaard

There is no way of doing that, RubParagraphDecorator lacks a method to set its style variable. If you add that, then you can do something like: Self is a RubEditingArea (self decoratorNamed: #shoutStyler) style: yourStyleclass new. Best regards, Henrik -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Yuriy Tymchuk Sent: Saturday, March 19, 2016 1:19 AM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: [Pharo-dev] How to set styler for RubEditingArea? Hi, I have my own styler which is a subclass of SHRBTextStyler. How do I set it as a styler for RubEditingArea? Cheers. Uko

March 19, 2016

How to set styler for RubEditingArea?

by Yuriy Tymchuk

Hi, I have my own styler which is a subclass of SHRBTextStyler. How do I set it as a styler for RubEditingArea? Cheers. Uko

March 19, 2016

3 new Pharo videos

by Torsten Bergmann

I provided 3 new videos about my tools/goodies on YouTube: Pharo OS-Linux-Ubuntu https://www.youtube.com/watch?v=1X42GFbW4hg Pharo Hubcap https://www.youtube.com/watch?v=2Kwr8bkSI7M Pharo Pomodoro https://www.youtube.com/watch?v=w00IBi9iM2Y

March 18, 2016

Re: [Pharo-dev] Changes Browser is broken

by Eliot Miranda

Hi > On Mar 17, 2016, at 4:33 PM, Ben Coman <btc(a)openinworld.com> wrote: > > I hadn't used Recover Changes for a while, but recently found that it > had lost a lot of power. Particularly not being able to filter to > show only the most recent updates. Its tedious to manually search for > the latest version of several methods. Also the middle button menu in the change list (which can also be used to import source files) has been reduced to just two items, rendering the tool much less powerful. A colleague and I were importing code from squeak the other day and were missing "select unchanged definitions", and others. Watching my colleague use the tool manually was painful. Someone should really put this functionality back. Look at the squeak tool for the most immediate reference. Look at VisualWorks for something more powerful still. Don't let it be said of Pharo: Don't it always seem to go That you don't know what you've got Til its gone They paved paradise And put up a parking lot ;-) _,,,^..^,,,_ (phone) Eliot > > cheers -ben > >> On Fri, Mar 18, 2016 at 6:30 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> Today I learned that you can actually lose code in Pharo because the record >> is not always added to the changes file. >> >> Also using the tool is quite a lot of pain, so if you want to recover your >> changes you have to do a lot of archaeology. >> >> I've added several issues and marked most of them as '2 - Really Important', >> because I think they are (especially for students etc that like to break >> things), but maybe you don't want it for Pharo 5. >> >> https://pharo.fogbugz.com/f/cases/17840/ChangesBrowser-selectAll-DNU >> https://pharo.fogbugz.com/f/cases/17841/Creating-a-class-from-a-debugger-du… >> https://pharo.fogbugz.com/f/cases/17842/Recover-lost-changes-doesn-t-recove… >> https://pharo.fogbugz.com/f/cases/17843/Changes-Browser-doesn-t-recover-cha… >> >> Peter >

March 18, 2016

Re: [Pharo-dev] [ANN] FFICHeaderExtractor first milestone (for early code reviewers) [WAS] Can OSProcess functionality be implemented using FFI instead of plugin?

by Mariano Martinez Peck

On Fri, Mar 18, 2016 at 10:06 AM, Damien Pollet <damien.pollet(a)gmail.com> wrote: > Hi Mariano, I just saw your comment in OSSUnixSystemAccessor >> getcwd and > wondered if there's a feasible plan for errno? What if the VM provided a > known accessor function around the global/macro/whatever errno is defined > as? > > Hi Damien, Unfortunately, that comment you read there happens not only for getcwd() but for every function that writes into errno. I already sent this to the mailing list and was discussed [1]. I have also chatted with Esteban about this, and Eliot said in VW VM they have something like this. To conclude, we lack such a support from FFI backend. We hope to add that at some point. Maybe Ronie will have some time to play with this? [1] http://forum.world.st/Question-about-errno-and-NB-FFI-td4867192.html > On 26 January 2016 at 08:15, stepharo <stepharo(a)free.fr> wrote: > >> super! >> >> Stef >> >> >> Le 25/1/16 23:27, Mariano Martinez Peck a Ã©crit : >> >> Hi guys, >> >> OK, I have a first working version and so I wanted to share it with you. >> >> I have not yet the time to start writing the doc since I just finished >> the first pass on the code. Tomorrow I will start with the doc. But I >> thought some of you may be interested in taking a look even without formal >> "doc" (and some feedback/iteration may avoid re-writing docs..). >> >> If you have no clue what I am talking about, then this summary is for you: >> >> *----------* >> *When we use FFI to call a certain library it's quite common that we >> need to pass as argument certain constants (for example, SIGKILL to >> kill()). These constants are defined in C header files and can even change >> it's value in different paltforms. * >> *These constants also are sometimes defined by the C preprocessor and so >> there is not way to get those values from FFI. If you don't have the value >> of those constants, you cannot make the FFI call. * >> *----------* >> >> I have tested the tool in OSX and CentOS using latest Pharo 5.0. It won't >> work in Windows right now. As usual, all classes and methods have comments >> and there are enough tests. >> >> At the end, I decided the C program will output a very naive Smalltalk >> literal array kind of thingy. The tool then parses that output and directly >> creates a init method (which is compiled into the SharedPool class) for >> that platform which is then called automatically at startup (only if >> initialization is needed). >> >> As for real examples, I started to write constants for libc: signal.h >> (to use kill()) , wait.h (to use wait() famility), fcntl.h (to use ... >> xxx()) , and errno.h. You can take a look to the >> package 'FFICHeaderExtractor-LibC'. >> >> Note that for running the tests you need 'cc' findable by path in OSX and >> 'gcc' in Unix. >> >> To load the code in a latest Pharo 5.0, execute: >> >> Metacello new >> baseline: 'FFICHeaderExtractor'; >> repository: >> 'github://marianopeck/FFICHeaderExtractor:master/repository'; >> load. >> Any feedback is appreciated. >> I will start writing the doc now. >> BTW: Big thanks to Eliot Miranda which helped me answering noob questions >> and providing useful code and guidelines. >> Best, >> >> >> On Sat, Jan 23, 2016 at 1:12 PM, Eliot Miranda < >> <eliot.miranda(a)gmail.com>eliot.miranda(a)gmail.com> wrote: >> >>> >>> Hi Denis, >>> >>> On Jan 23, 2016, at 7:30 AM, Denis Kudriashov < <dionisiydk(a)gmail.com> >>> dionisiydk(a)gmail.com> wrote: >>> >>> >>> 2016-01-22 22:35 GMT+01:00 Eliot Miranda < <eliot.miranda(a)gmail.com> >>> eliot.miranda(a)gmail.com>: >>> >>>> Let's measure this. Let's say we have 8 platforms (that's an >>>> underestimate, because different Linux distributions may have different >>>> values for certain constants), but 8, which is 4 basic platforms times 32- >>>> & 64-bits. We have Mac x86 32-bit, Mac x64 64-bit, Windows x86 >>>> 32-bit, Windows x64 64-bit, Linux x86 32-bit, Linux ARM 32-bit, Linux x64 >>>> 64-bit, and soon enough there will be more. Further, there may be >>>> different versions over time. >>>> >>>> So each of those initialization methods has >>>> - 1 slot for the global variable to be assigned >>>> - 1 slot for the literal value to assign to it >>>> - 3 bytes of bytecode per initialization for small methods, 4 for large >>>> methods. Let's say 4. >>>> >>>> So the overhead in 32-bits is 12 bytes per constant, and in 64-bits is >>>> 20 bytes. So the overhead per constant for all platforms is 96 bytes per >>>> constant in 32-bits and 160 bytes per constant for 64-bits. A full system >>>> with sockets, files, a database connexion etc could easily exceed 100 >>>> constants. I think it would be nearer 1000. So the overheads are in the >>>> 10- to 100-k byte range (100k ~= 0.5% of the image) on 32-bits. That's low >>>> but it's also pure overhead. Every GC has to visit them. Every senders >>>> and implementors has to visit them, but they offer nothing of value. >>>> Whereas the small parser for whatever notation is used to store the >>>> constants externally (if they are needed in a given deployment) has a small >>>> constant overhead; its simple code. >>>> >>>> Further, you still need the machinery to export the constants to be >>>> able to generate these initialization methods. If you've got the machinery >>>> and you don't need the methods why bother to generate the methods? >>>> >>>> As the Scots say, many a mickle makes a muckle. >>> >>> >>> Thank's Eliot for such detailed explanation. It makes sense. >>> But personally I prefer Smalltalk solution although Smalltalk itself is >>> pure overhead comparing to C. >>> >>> >>> I can see the draw of the pure Smalltalk. Simplicity and brows ability. >>> But imagine a tiny headless image deployed on containers, say 2mb. Now >>> 100kb of initialization code doesn't look so good :-). Anyway I'm beating >>> a dead horse. Mariano is generating initialization methods. >>> >>> >>> My question was raised by Mariano idea to save ston files in methods. I >>> think it can reduce problems which you described. >>> But then literal array syntax can be more suitable than ston. >>> >>> >>> I just want to be clear, I'm neutral about the notation used to export >>> info from the C file. Liberal array syntax, chunk source format, ston, >>> xml. It doesn't matter as long as it's convenient at expressing an >>> attribute dictionary from names to attributes such as value, size, offset. >>> Don't get hung up on the specific notation. If one were to go with the >>> external file the only real requirements are that it be reasonably compact >>> and quick to parse. That might kill xml but leave plenty of other >>> candidates. >>> >>> >>> _,,,^..^,,,_ (phone) >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > -- Mariano http://marianopeck.wordpress.com

March 18, 2016

Re: [Pharo-dev] [ANN] FFICHeaderExtractor first milestone (for early code reviewers) [WAS] Can OSProcess functionality be implemented using FFI instead of plugin?

by Damien Pollet

Hi Mariano, I just saw your comment in OSSUnixSystemAccessor >> getcwd and wondered if there's a feasible plan for errno? What if the VM provided a known accessor function around the global/macro/whatever errno is defined as? On 26 January 2016 at 08:15, stepharo <stepharo(a)free.fr> wrote: > super! > > Stef > > > Le 25/1/16 23:27, Mariano Martinez Peck a Ã©crit : > > Hi guys, > > OK, I have a first working version and so I wanted to share it with you. > > I have not yet the time to start writing the doc since I just finished the > first pass on the code. Tomorrow I will start with the doc. But I thought > some of you may be interested in taking a look even without formal "doc" > (and some feedback/iteration may avoid re-writing docs..). > > If you have no clue what I am talking about, then this summary is for you: > > *----------* > *When we use FFI to call a certain library it's quite common that we > need to pass as argument certain constants (for example, SIGKILL to > kill()). These constants are defined in C header files and can even change > it's value in different paltforms. * > *These constants also are sometimes defined by the C preprocessor and so > there is not way to get those values from FFI. If you don't have the value > of those constants, you cannot make the FFI call. * > *----------* > > I have tested the tool in OSX and CentOS using latest Pharo 5.0. It won't > work in Windows right now. As usual, all classes and methods have comments > and there are enough tests. > > At the end, I decided the C program will output a very naive Smalltalk > literal array kind of thingy. The tool then parses that output and directly > creates a init method (which is compiled into the SharedPool class) for > that platform which is then called automatically at startup (only if > initialization is needed). > > As for real examples, I started to write constants for libc: signal.h (to > use kill()) , wait.h (to use wait() famility), fcntl.h (to use ... xxx()) , > and errno.h. You can take a look to the package 'FFICHeaderExtractor-LibC'. > > Note that for running the tests you need 'cc' findable by path in OSX and > 'gcc' in Unix. > > To load the code in a latest Pharo 5.0, execute: > > Metacello new > baseline: 'FFICHeaderExtractor'; > repository: > 'github://marianopeck/FFICHeaderExtractor:master/repository'; > load. > Any feedback is appreciated. > I will start writing the doc now. > BTW: Big thanks to Eliot Miranda which helped me answering noob questions > and providing useful code and guidelines. > Best, > > > On Sat, Jan 23, 2016 at 1:12 PM, Eliot Miranda < <eliot.miranda(a)gmail.com> > eliot.miranda(a)gmail.com> wrote: > >> >> Hi Denis, >> >> On Jan 23, 2016, at 7:30 AM, Denis Kudriashov < <dionisiydk(a)gmail.com> >> dionisiydk(a)gmail.com> wrote: >> >> >> 2016-01-22 22:35 GMT+01:00 Eliot Miranda < <eliot.miranda(a)gmail.com> >> eliot.miranda(a)gmail.com>: >> >>> Let's measure this. Let's say we have 8 platforms (that's an >>> underestimate, because different Linux distributions may have different >>> values for certain constants), but 8, which is 4 basic platforms times 32- >>> & 64-bits. We have Mac x86 32-bit, Mac x64 64-bit, Windows x86 >>> 32-bit, Windows x64 64-bit, Linux x86 32-bit, Linux ARM 32-bit, Linux x64 >>> 64-bit, and soon enough there will be more. Further, there may be >>> different versions over time. >>> >>> So each of those initialization methods has >>> - 1 slot for the global variable to be assigned >>> - 1 slot for the literal value to assign to it >>> - 3 bytes of bytecode per initialization for small methods, 4 for large >>> methods. Let's say 4. >>> >>> So the overhead in 32-bits is 12 bytes per constant, and in 64-bits is >>> 20 bytes. So the overhead per constant for all platforms is 96 bytes per >>> constant in 32-bits and 160 bytes per constant for 64-bits. A full system >>> with sockets, files, a database connexion etc could easily exceed 100 >>> constants. I think it would be nearer 1000. So the overheads are in the >>> 10- to 100-k byte range (100k ~= 0.5% of the image) on 32-bits. That's low >>> but it's also pure overhead. Every GC has to visit them. Every senders >>> and implementors has to visit them, but they offer nothing of value. >>> Whereas the small parser for whatever notation is used to store the >>> constants externally (if they are needed in a given deployment) has a small >>> constant overhead; its simple code. >>> >>> Further, you still need the machinery to export the constants to be able >>> to generate these initialization methods. If you've got the machinery and >>> you don't need the methods why bother to generate the methods? >>> >>> As the Scots say, many a mickle makes a muckle. >> >> >> Thank's Eliot for such detailed explanation. It makes sense. >> But personally I prefer Smalltalk solution although Smalltalk itself is >> pure overhead comparing to C. >> >> >> I can see the draw of the pure Smalltalk. Simplicity and brows ability. >> But imagine a tiny headless image deployed on containers, say 2mb. Now >> 100kb of initialization code doesn't look so good :-). Anyway I'm beating >> a dead horse. Mariano is generating initialization methods. >> >> >> My question was raised by Mariano idea to save ston files in methods. I >> think it can reduce problems which you described. >> But then literal array syntax can be more suitable than ston. >> >> >> I just want to be clear, I'm neutral about the notation used to export >> info from the C file. Liberal array syntax, chunk source format, ston, >> xml. It doesn't matter as long as it's convenient at expressing an >> attribute dictionary from names to attributes such as value, size, offset. >> Don't get hung up on the specific notation. If one were to go with the >> external file the only real requirements are that it be reasonably compact >> and quick to parse. That might kill xml but leave plenty of other >> candidates. >> >> >> _,,,^..^,,,_ (phone) >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

March 18, 2016

Re: [Pharo-dev] Changes Browser is broken

by stepharo

Thanks henrik you were faster than us... I had to finish an exercise for the mooc. Stef Le 18/3/16 10:53, Peter UhnÃ¡k a Ã©crit : > On Fri, Mar 18, 2016 at 8:58 AM, Esteban Lorenzano > <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > > yes, Epicea will be integrated âfirst week of Pharo 6â, so we can > iterate and > > Well we still need to fix it, we can't leave Pharo 5 for a year > without a proper recovery. > We'll try to fix something today with Stef. > > Peter

March 18, 2016

Re: [Pharo-dev] Changes Browser is broken

by Sven Van Caekenberghe

Ah, that is a secret Norwegian agent ! > On 18 Mar 2016, at 12:34, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Actually the thanks here goes to Latsabben ( that fixed most of it before I could even start looking at the code. :) > > Peter > > On Fri, Mar 18, 2016 at 12:30 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > THANK YOU !! > > (but you had a secret French special agent, right ;-) > > > On 18 Mar 2016, at 12:26, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > 12 hours later all the bugs are fixed. > > > > And that's why I love Pharo and everyone here. :) > > > > Thanks! > > > > On Fri, Mar 18, 2016 at 10:53 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > On Fri, Mar 18, 2016 at 8:58 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > yes, Epicea will be integrated âfirst week of Pharo 6â, so we can iterate and > > > > Well we still need to fix it, we can't leave Pharo 5 for a year without a proper recovery. > > We'll try to fix something today with Stef. > > > > Peter > > > > >

March 18, 2016