Archive for March, 2011

A C++ feature I would love to have: custom type modifiers

In C++ the const type mod­i­fiers when applied to meth­ods has the nice prop­erty of mak­ing it impos­si­ble by default (e.g. with­out a const_cast) to call non-const meth­ods. A sim­i­lar fea­ture is pro­vided by C++0x key­word con­s­t­expr.

It would be very nice if this prop­erty could be applied to cus­tom classes of func­tions. The idea would be to tag method def­i­n­i­tions with a cus­tom key­word, or a type. Tagged meth­ods would then only be able to call method tagged with the same type.

A nice usage I could find for this would be to define a non-blocking class of meth­ods. Non block­ing meth­ods are such if they never blocks for a poten­tially unbounded amount of time wait­ing for an event. Using the tags the com­piler will be able to detect if a method sup­posed to be non-blocking is try­ing to call some poten­tially block­ing code and this would be very use­ful to detect pos­si­ble dead­locks at com­pile time. Another usage would be to tag all the meth­ods that are sup­posed to be used by a spe­cific thread with the same tag. With such setup meth­ods that access shared data would be untagged and using them would require a cast or some spe­cial syn­tax, hope­fully help­ing the pro­gram­mer remem­ber that some syn­chro­niza­tion is needed.

A pos­si­ble approach to (ab)use the volatile key­word to detect race con­di­tions was described here in 2001. But maybe this approach could be more gen­eral. Any com­ment?

Flattr this

, ,

6 Comments

A C++ feature I would love to have: custom type modifiers

In C++ the const type mod­i­fiers when applied to meth­ods has the nice prop­erty of mak­ing it impos­si­ble by default (e.g. with­out a const_cast) to call non-const meth­ods. A sim­i­lar fea­ture is pro­vided by C++0x key­word con­s­t­expr.

It would be very nice if this prop­erty could be applied to cus­tom classes of func­tions. The idea would be to tag method def­i­n­i­tions with a cus­tom key­word, or a type. Tagged meth­ods would then only be able to call method tagged with the same type.

A nice usage I could find for this would be to define a non-blocking class of meth­ods. Non block­ing meth­ods are such if they never blocks for a poten­tially unbounded amount of time wait­ing for an event. Using the tags the com­piler will be able to detect if a method sup­posed to be non-blocking is try­ing to call some poten­tially block­ing code and this would be very use­ful to detect pos­si­ble dead­locks at com­pile time. Another usage would be to tag all the meth­ods that are sup­posed to be used by a spe­cific thread with the same tag. With such setup meth­ods that access shared data would be untagged and using them would require a cast or some spe­cial syn­tax, hope­fully help­ing the pro­gram­mer remem­ber that some syn­chro­niza­tion is needed.

A pos­si­ble approach to (ab)use the volatile key­word to detect race con­di­tions was described here in 2001. But maybe this approach could be more gen­eral. Any com­ment?

Flattr this

, ,

6 Comments

Lightspark 0.4.6.1 released

Ver­sion 0.4.6 was released no more than a free days ago, but unfor­tu­nately a change in the YouTube player exposed a bug that could cause browser crashes. Ver­sion 0.4.6.1 fixes the issue and updat­ing is recommended.

I’d also like to share some though and explain why we need to make so many point releases to keep things work­ing. Lightspark shares a lot of sim­i­lar­ity with the Wine project in my opin­ion, as both projects aims at reim­ple­ment­ing from scratch a large (huge for Wine, of course) plat­form for third party applications.

The “advan­tage” for Wine is that exe­cuta­bles for installed pro­grams (e.g. Microsoft Word) change not so often, and usu­ally updat­ing is under the con­trol of the user. A user that is inter­ested in keep­ing Wine com­pat­i­ble with a cer­tain appli­ca­tion is, most often, free to delay the update until Wine catches up.

Lightspark, on the other hand, needs to exe­cute con­tents (e.g. YouTube video player) that are mostly out of the user con­trol and new, incom­pat­i­ble, ver­sions of the con­tents may pop out at any­time and there is very lit­tle we can do about it.

The only way we can be faith­ful to the adver­tised “YouTube[*] sup­port” is to improve our code when­ever a break­age pops up. I under­stand this is also chal­leng­ing for dis­tros and pack­agers because the life span of our sta­ble releases is linked to quite unpre­dictable events and I’d like to say “thank you” to all the peo­ple pack­ag­ing lightspark for dis­tros in the wild. Your work is exceptional.

[*] As a side note, although cur­rently only YouYube sup­port is sta­ble enough to be used daily, Lightspark is not an YT spe­cific hack. Sup­port for other sites is com­ing along slowly given our lim­ited work­force. I’ve done some work to have hulu work­ing and I think we’re now 80% done in sup­port­ing it. If any­one is inter­ested in con­tribut­ing to lightspark to have Hulu (or any other pop­u­lar site) sup­ported, please drop by #lightspark IRC chan­nel on Freen­ode

Flattr this

, , , , ,

6 Comments

Lightspark 0.4.6.1 released

Ver­sion 0.4.6 was released no more than a free days ago, but unfor­tu­nately a change in the YouTube player exposed a bug that could cause browser crashes. Ver­sion 0.4.6.1 fixes the issue and updat­ing is recommended.

I’d also like to share some though and explain why we need to make so many point releases to keep things work­ing. Lightspark shares a lot of sim­i­lar­ity with the Wine project in my opin­ion, as both projects aims at reim­ple­ment­ing from scratch a large (huge for Wine, of course) plat­form for third party applications.

The “advan­tage” for Wine is that exe­cuta­bles for installed pro­grams (e.g. Microsoft Word) change not so often, and usu­ally updat­ing is under the con­trol of the user. A user that is inter­ested in keep­ing Wine com­pat­i­ble with a cer­tain appli­ca­tion is, most often, free to delay the update until Wine catches up.

Lightspark, on the other hand, needs to exe­cute con­tents (e.g. YouTube video player) that are mostly out of the user con­trol and new, incom­pat­i­ble, ver­sions of the con­tents may pop out at any­time and there is very lit­tle we can do about it.

The only way we can be faith­ful to the adver­tised “YouTube[*] sup­port” is to improve our code when­ever a break­age pops up. I under­stand this is also chal­leng­ing for dis­tros and pack­agers because the life span of our sta­ble releases is linked to quite unpre­dictable events and I’d like to say “thank you” to all the peo­ple pack­ag­ing lightspark for dis­tros in the wild. Your work is exceptional.

[*] As a side note, although cur­rently only YouYube sup­port is sta­ble enough to be used daily, Lightspark is not an YT spe­cific hack. Sup­port for other sites is com­ing along slowly given our lim­ited work­force. I’ve done some work to have hulu work­ing and I think we’re now 80% done in sup­port­ing it. If any­one is inter­ested in con­tribut­ing to lightspark to have Hulu (or any other pop­u­lar site) sup­ported, please drop by #lightspark IRC chan­nel on Freen­ode

Flattr this

, , , , ,

6 Comments

Lightspark 0.4.6 released

I’m happy to announce that a new ver­sion of Lightspark flash player has been released. The release fea­tures improved sta­bil­ity and graphics:

  • Gra­di­ent sup­port has been vastly improved
  • Graph­i­cal glitches are greatly reduced
  • Added sup­port for the upcom­ing gnash 0.8.9 release
  • Added sup­port for pro­fil­ing Action­Script code
  • Added sup­port for mut­ing all sound by press­ing ‘m’
  • Added sup­port for copy­ing error mes­sages to the clip­board by press­ing ”c’

The tar­ball is, as usual, avail­able on Launch­Pad. Binary pack­ages for Ubuntu mav­er­ick and natty are avail­able from the Spark­ers Team PPA.

Pack­ages for Debian and Fedora will be avail­able soon.


Flattr this

,

9 Comments

Lightspark 0.4.6 released

I’m happy to announce that a new ver­sion of Lightspark flash player has been released. The release fea­tures improved sta­bil­ity and graphics:

  • Gra­di­ent sup­port has been vastly improved
  • Graph­i­cal glitches are greatly reduced
  • Added sup­port for the upcom­ing gnash 0.8.9 release
  • Added sup­port for pro­fil­ing Action­Script code
  • Added sup­port for mut­ing all sound by press­ing ‘m’
  • Added sup­port for copy­ing error mes­sages to the clip­board by press­ing ”c’

The tar­ball is, as usual, avail­able on Launch­Pad. Binary pack­ages for Ubuntu mav­er­ick and natty are avail­able from the Spark­ers Team PPA.

Pack­ages for Debian and Fedora will be avail­able soon.


Flattr this

,

9 Comments