December 2013 - Pharo-dev - lists.pharo.org

[OT] ouch! Too few likes?

by Sebastian Sastre

Hi there, I don't believe in vanity metrics but I'm receiving some critics about low quantity of likes that would be nice to answer. Can you help us boost this pharo-powered app with your like here? https://www.facebook.com/airflowing Many many thanks! Also this should help us to promote it later if we choose to because facebook itself requires a minimum of likes to give you commercial campaign tools Again thank you for your support! sebastian o/ PD: sorry we're prioritising portuguese there but most of our paying clients are in fact from Brazil, thanks again!

Dec. 19, 2013

Re: [Pharo-dev] Why Color rgb components are on 10 bits?

by Nicolas Cellier

2013/12/19 <btc(a)openinworld.com> > Nicolas Cellier wrote: > >> I know the answer, we have 30 bits available for keeping the rgb instance >> variable as SmallInteger... >> So it's the best we can do, while keeping an efficient format. >> >> But we are never using 10 bits for each component, for 32 bits image only >> 8 bit by color are used. >> Since nowadays most Forms are 32 bits deep, this force useless >> conversions where we could have none. >> >> I see that Pharo 3.0 did unify Color and TranslucentColor by moving the >> alpha information in Color. >> But did not change the rgb ComponentMax... Any reason why? >> >> If we encoded rgb component on 8 bits, and reverted the alpha channel >> encoding, then we could have colors pre-encoded on 32 bits, but most using >> only 24 bits (because most are opaque) would be represented as SmallInteger. >> But I don't know if it is really inter-operable, or more natural... >> >> Juan followed another path for Cuis, opting for float components, which >> is another possibility, but our VM are not yet optimized for handling >> Floats... >> >> Thoughts? >> > Could 6 bits be enough for transparency? Perhaps only for Pharo's own > system & UI stuff. Any bitmap editor application would probably need to > extend to handle the full 8 bit alpha. Or maybe that adds unneeded > complexity. > > cheers -ben > > Yes, it would be sufficient, but it seems simpler to manage a separate 8 bit alpha channel as it is the case now.

Dec. 19, 2013

Re: [Pharo-dev] [squeak-dev] Why Color rgb components are on 10 bits?

by Nicolas Cellier

2013/12/19 Bert Freudenberg <bert(a)freudenbergs.de> > > On 19.12.2013, at 18:06, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > I know the answer, we have 30 bits available for keeping the rgb instance > variable as SmallInteger... > So it's the best we can do, while keeping an efficient format. > > But we are never using 10 bits for each component, for 32 bits image only > 8 bit by color are used. > Since nowadays most Forms are 32 bits deep, this force useless conversions > where we could have none. > > I see that Pharo 3.0 did unify Color and TranslucentColor by moving the > alpha information in Color. > But did not change the rgb ComponentMax... Any reason why? > > If we encoded rgb component on 8 bits, and reverted the alpha channel > encoding, then we could have colors pre-encoded on 32 bits, but most using > only 24 bits (because most are opaque) would be represented as SmallInteger. > But I don't know if it is really inter-operable, or more natural... > > Juan followed another path for Cuis, opting for float components, which is > another possibility, but our VM are not yet optimized for handling Floats... > > Thoughts? > > > All opaque colors would be LargeIntegers, not SmallIntegers: 16rFFxxxxxx. > > - Bert - > > Yes, that's why we would need to invert the encoding of alpha channel... But this change would be much more intrusive (change primitives...), and not really compatible with established practices where alpha channel is interpreted as opcity level, not as transparency level ( http://en.wikipedia.org/wiki/RGBA_color_space) I think we can forget this part of the proposition which is too much Smalltalk-centric. Nicolas

Dec. 19, 2013

Re: [Pharo-dev] Why Color rgb components are on 10 bits?

by btc＠openinworld.com

Nicolas Cellier wrote: > I know the answer, we have 30 bits available for keeping the rgb > instance variable as SmallInteger... > So it's the best we can do, while keeping an efficient format. > > But we are never using 10 bits for each component, for 32 bits image > only 8 bit by color are used. > Since nowadays most Forms are 32 bits deep, this force useless > conversions where we could have none. > > I see that Pharo 3.0 did unify Color and TranslucentColor by moving > the alpha information in Color. > But did not change the rgb ComponentMax... Any reason why? > > If we encoded rgb component on 8 bits, and reverted the alpha channel > encoding, then we could have colors pre-encoded on 32 bits, but most > using only 24 bits (because most are opaque) would be represented as > SmallInteger. > But I don't know if it is really inter-operable, or more natural... > > Juan followed another path for Cuis, opting for float components, > which is another possibility, but our VM are not yet optimized for > handling Floats... > > Thoughts? Could 6 bits be enough for transparency? Perhaps only for Pharo's own system & UI stuff. Any bitmap editor application would probably need to extend to handle the full 8 bit alpha. Or maybe that adds unneeded complexity. cheers -ben

Dec. 19, 2013

Why Color rgb components are on 10 bits?

by Nicolas Cellier

I know the answer, we have 30 bits available for keeping the rgb instance variable as SmallInteger... So it's the best we can do, while keeping an efficient format. But we are never using 10 bits for each component, for 32 bits image only 8 bit by color are used. Since nowadays most Forms are 32 bits deep, this force useless conversions where we could have none. I see that Pharo 3.0 did unify Color and TranslucentColor by moving the alpha information in Color. But did not change the rgb ComponentMax... Any reason why? If we encoded rgb component on 8 bits, and reverted the alpha channel encoding, then we could have colors pre-encoded on 32 bits, but most using only 24 bits (because most are opaque) would be represented as SmallInteger. But I don't know if it is really inter-operable, or more natural... Juan followed another path for Cuis, opting for float components, which is another possibility, but our VM are not yet optimized for handling Floats... Thoughts?

Dec. 19, 2013

Re: [Pharo-dev] Problem with wrapping text in pdf documentation

by Damien Cassou

On Thu, Dec 19, 2013 at 11:54 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > Take a look here > > https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSucces… > > code is cut out and does not wrap. Looks it exceeds its boundaries. Maybe > some sort of bug ? Fixed. That was a problem in the sources. The text was: =User >> fuelAfterMaterialization = acumulatedLogins := 0. whereas it should have been: [[[language=Smalltalk User >> fuelAfterMaterialization acumulatedLogins := 0. ]]] -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Dec. 19, 2013

Re: [Pharo-dev] UDP Broadcast message

by Esteban A. Maringolo

2013/12/19 Sven Van Caekenberghe <sven(a)stfx.eu>: > On 19 Dec 2013, at 17:09, jannik.laval <jannik.laval(a)gmail.com> wrote: >> No more need of Wireshark. > Great ! > When it works (and one way or another is usually does), Pharo is a great/excellent tool for doing all sorts of network, binary and bit hacking. A thousand times more practical and useful than low level languages: you have great interactivity, discoverability and debug capabilities in a super environment where you can really work with objects (and thus bytes, bits and byte arrays). +1 Years ago I implemented a client (in VB6) for a proprietary binary feed, but because I didn't have the server available, I was able to implement the interface with Smalltalk. Being able to inspect the contents of a socket, and iterate as you like is a true advantage. Regards! Esteban A. Maringolo

Dec. 19, 2013

files.pharo.org maintenance

by Christophe Demarey

Hello, A maintenance operation will be performed on files.pharo.org to add more storage. It will be performed Monday, December 23rd 2013 between 3:00 pm and 3:30 pm. Zero conf scripts and CI jobs will fail if used at this time. Regards, Christophe.

Dec. 19, 2013

NativeBoost and standard out

by Emilio Oca

Hi Is it possible to get the stdout results when running WinProcess createAndWaitForProcess: aCommand?. If it is not, any alternative? Best Emilio

Dec. 19, 2013

Re: [Pharo-dev] UDP Broadcast message

by Sven Van Caekenberghe

On 19 Dec 2013, at 17:09, jannik.laval <jannik.laval(a)gmail.com> wrote: > Ohhhhhh yessss ! > Thank you, It works fine ! > > No more need of Wireshark. Great ! When it works (and one way or another is usually does), Pharo is a great/excellent tool for doing all sorts of network, binary and bit hacking. A thousand times more practical and useful than low level languages: you have great interactivity, discoverability and debug capabilities in a super environment where you can really work with objects (and thus bytes, bits and byte arrays). You still have to know what you are doing, of course ;-) Sven > Thank you again. > Jannik > > On Dec 19, 2013, at 4:40 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> You also have to set a port with #setPort: no ? >> >> On 19 Dec 2013, at 16:39, jannik.laval <jannik.laval(a)gmail.com> wrote: >> >>> And here is my small example code: >>> >>> udpSocket := Socket newUDP. >>> udpSocket setOption: 'SO_BROADCAST' value: true. >>> udpSocket getOption: 'SO_BROADCAST'. >>> udpSocket receiveDataTimeout: 15. >>> >>> >>> Jannik >>> >>> On Dec 19, 2013, at 4:29 PM, jannik.laval <jannik.laval(a)gmail.com> wrote: >>> >>>> Ok, here is my situation: >>>> >>>> - I have a Lego Mindstorm that broadcast a UDP message every 10 seconds. >>>> - With Wireshark I can see the UDP message, so no problem with that. >>>> - I tried to set the option SO_BROADCAST, it does not work anymore. >>>> >>>> Any other idea ? >>>> >>>> Jannik >>>> >>>> On Dec 19, 2013, at 4:14 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: >>>> >>>>> Norbert wrote: >>>>>> To send or receive a broadcast packet you need to put special options on the socket on the native side (setsockopt). You need to >look if the SO_BROADCAST option is mentioned anywhere. If not it wonât work without adding them. And for sending them you >need almost special privileges on the system. This is not a âuser featureâ. >>>>> >>>>> And even though it is "the right thing" for lots of situations, your network is also very likely to not do the right thing >>>>> with broadcast packets. Etsy decided on using bittorrent protocol to update their production servers indexes, because they >>>>> found it too difficult to get their network to do the right thing. They found that their switches were basically livelocked >>>>> while dealing with broadcast packets. >>>>> >>>>> http://codeascraft.com/2012/01/23/solr-bittorrent-index-replication/ >>>>> >>>>> If you want the broadcast to travel a little further, the routers need to be configured not to drop the packets. >>>>> >>>>> Stephan >>>> >>> >> >> > > -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

Dec. 19, 2013