[fonc] Sussman on InfoQ: We Really Don't Know How To Compute!
http://www.infoq.com/presentations/We-Really-Dont-Know-How-To-Compute ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] new document
On Nov 7, 2011, at 6:08 PM, karl ramberg wrote: http://www.vpri.org/pdf/tr2011004_steps11.pdf It's so exciting to watch the project come along. I can't wait to eventually play with it! With every annual report, I think what a shame it is that there are so many talks given about it (~20 this year) and so few (~3) are recorded. Given the vital importance of this project, and all the work that must go into preparing the talks, it seems like a great waste to share this knowledge with only the few academics who happen to be at the various conferences. I attend about 6 conferences a year and still feel like I'm missing all the fun. Why doesn't VPRI just take the bull by the horns and record them even if the conferences don't? Consumer video equipment is so good now, it probably wouldn't cost anything but a few conversations - even an iPhone video could work! Sean ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] new document
+1 Joel Healy On Tue, Nov 8, 2011 at 10:49 AM, DeNigris Sean s...@clipperadams.comwrote: On Nov 7, 2011, at 6:08 PM, karl ramberg wrote: http://www.vpri.org/pdf/tr2011004_steps11.pdf It's so exciting to watch the project come along. I can't wait to eventually play with it! With every annual report, I think what a shame it is that there are so many talks given about it (~20 this year) and so few (~3) are recorded. Given the vital importance of this project, and all the work that must go into preparing the talks, it seems like a great waste to share this knowledge with only the few academics who happen to be at the various conferences. I attend about 6 conferences a year and still feel like I'm missing all the fun. Why doesn't VPRI just take the bull by the horns and record them even if the conferences don't? Consumer video equipment is so good now, it probably wouldn't cost anything but a few conversations - even an iPhone video could work! Sean ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] new document
+1 !!
]{evin ])riedger
On Tue, Nov 8, 2011 at 1:05 PM, Joel Healy joel.h.he...@gmail.com wrote:
+1
Joel Healy
On Tue, Nov 8, 2011 at 10:49 AM, DeNigris Sean s...@clipperadams.comwrote:
On Nov 7, 2011, at 6:08 PM, karl ramberg wrote:
http://www.vpri.org/pdf/tr2011004_steps11.pdf
It's so exciting to watch the project come along. I can't wait to
eventually play with it!
With every annual report, I think what a shame it is that there are so
many talks given about it (~20 this year) and so few (~3) are recorded.
Given the vital importance of this project, and all the work that must go
into preparing the talks, it seems like a great waste to share this
knowledge with only the few academics who happen to be at the various
conferences. I attend about 6 conferences a year and still feel like I'm
missing all the fun. Why doesn't VPRI just take the bull by the horns and
record them even if the conferences don't? Consumer video equipment is so
good now, it probably wouldn't cost anything but a few conversations - even
an iPhone video could work!
Sean
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] new document
I would like to see dedicated papers or links on Gezira and Nile - enough to re-implement them in another language. I expect techniques as used in Vertigo [1] or GPipe [2] could put Nile directly on a GPU, via pixel and geometry shaders. This would be a far better proof-of-concept, IMO, than relying on user threads across 40 cores to get a 30x speedup. [1] http://conal.net/Vertigo/ [2] http://www.haskell.org/haskellwiki/GPipe/Tutorial On Mon, Nov 7, 2011 at 3:08 PM, karl ramberg karlramb...@gmail.com wrote: http://www.vpri.org/pdf/tr2011004_steps11.pdf Karl ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] new document
Thanks.
On Tue, Nov 8, 2011 at 12:21 PM, Kevin Driedger linuxbox+f...@gmail.comwrote:
Both are available on github.
Gizera:
https://github.com/damelang/gezira
Nile:
https://github.com/damelang/nile
Perhaps that could get you started.
]{evin
On Tue, Nov 8, 2011 at 3:09 PM, David Barbour dmbarb...@gmail.com wrote:
I would like to see dedicated papers or links on Gezira and Nile - enough
to re-implement them in another language.
I expect techniques as used in Vertigo [1] or GPipe [2] could put Nile
directly on a GPU, via pixel and geometry shaders. This would be a far
better proof-of-concept, IMO, than relying on user threads across 40 cores
to get a 30x speedup.
[1] http://conal.net/Vertigo/
[2] http://www.haskell.org/haskellwiki/GPipe/Tutorial
On Mon, Nov 7, 2011 at 3:08 PM, karl ramberg karlramb...@gmail.comwrote:
http://www.vpri.org/pdf/tr2011004_steps11.pdf
Karl
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
[fonc] Fwd: [AGERE! at SPLASH] Talks by Mark Miller
Some on this list with interests in security may enjoy these, too... Related: - The AGERE! (Actors and Agents Reloaded) workshop webpage: http://www.alice.unibo.it/xwiki/bin/view/AGERE/ - AmbientTalk (actor language for mobile devices): http://soft.vub.ac.be/amop/ -- Max -- Forwarded message -- From: Tom Van Cutsem tomvc...@gmail.com Date: Thu, Nov 3, 2011 at 12:37 PM Subject: [AGERE! at SPLASH] Talks by Mark Miller To: agere-at-spl...@googlegroups.com Dear all, During the panel session, Mark Miller showed some slides from a talk he gave at our university (University of Brussels, Belgium) a couple of weeks ago. At the workshop, I promised to forward links to the videos of the full talks when they would become available. See the abstract and links below. How does this relate to actors? Mark talks about capability-based security, which meshes really well with object-oriented, and - in the distributed case - with actor-based programming. Don't worry if you are not an expert on security: Mark explains the issues in a very clear and understandable way. Thanks again to the organizers for a successful AGERE! workshop. Kind regards, Tom Van Cutsem Talk 1/2: Secure Distributed Programming with Object-capabilities in JavaScript Until now, browser-based security has been hell. The object-capability (ocap) model provides a simple and expressive alternative. Google's Caja project uses the latest JavaScript standard, EcmaScript 5, to support fine-grained safe mobile code, solving the secure mashup problem. Dr. SES -- Distributed Resilient Secure EcmaScript -- extends the ocap model cryptographically over the network, enabling RESTful composition of mutually suspicious web services. We show how to apply the expressiveness of object programming to the expression of security patterns, solving security problems normally thought to be difficult with simple elegant programs. Slides: http://soft.vub.ac.be/events/mobicrant_talks/talk1_ocaps_js.pdf Video: http://www.youtube.com/watch?v=w9hHHvhZ_HY Talk 2/2: Bringing Object-orientation to Security Programming Just as we should not expect our base programming language to provide all the data types we need, so we should not expect our security foundation to provide all the abstractions we need to express security policy. The answer to both is the same: We need foundations that provide simple abstraction mechanisms, which we use to build an open ended set of abstractions, which we then use to express policy. We show how to use EcmaScript 5 to enforce the security latent in object-oriented abstraction mechanisms: encapsulation, message-passing, polymorphism, and interposition. With these secured, we show how to build abstractions for confinement, rights amplification, transitive wrapping and revocation, and smart contracts. Slides: http://soft.vub.ac.be/events/mobicrant_talks/talk2_OO_security.pdf Video: http://www.youtube.com/watch?v=oBqeDYETXME -- You received this message because you are subscribed to the Google Groups AGERE! at SPLASH group. To post to this group, send email to agere-at-spl...@googlegroups.com. To unsubscribe from this group, send email to agere-at-splash+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/agere-at-splash?hl=en. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
RE: [fonc] Fwd: [AGERE! at SPLASH] Talks by Mark Miller
I was able to attend the AGERE! Workshop at Splash. Very interesting concepts. I'm interested to see how Actor based programming can enter the mainstream programming to provide some consistency in EDA systems. John Mickey Brown - Application Architect From: fonc-boun...@vpri.org [mailto:fonc-boun...@vpri.org] On Behalf Of Max OrHai Sent: Tuesday, November 08, 2011 3:54 PM To: Fundamentals of New Computing Subject: [fonc] Fwd: [AGERE! at SPLASH] Talks by Mark Miller Some on this list with interests in security may enjoy these, too... Related: - The AGERE! (Actors and Agents Reloaded) workshop webpage: http://www.alice.unibo.it/xwiki/bin/view/AGERE/ - AmbientTalk (actor language for mobile devices): http://soft.vub.ac.be/amop/ -- Max -- Forwarded message -- From: Tom Van Cutsem tomvc...@gmail.commailto:tomvc...@gmail.com Date: Thu, Nov 3, 2011 at 12:37 PM Subject: [AGERE! at SPLASH] Talks by Mark Miller To: agere-at-spl...@googlegroups.commailto:agere-at-spl...@googlegroups.com Dear all, During the panel session, Mark Miller showed some slides from a talk he gave at our university (University of Brussels, Belgium) a couple of weeks ago. At the workshop, I promised to forward links to the videos of the full talks when they would become available. See the abstract and links below. How does this relate to actors? Mark talks about capability-based security, which meshes really well with object-oriented, and - in the distributed case - with actor-based programming. Don't worry if you are not an expert on security: Mark explains the issues in a very clear and understandable way. Thanks again to the organizers for a successful AGERE! workshop. Kind regards, Tom Van Cutsem Talk 1/2: Secure Distributed Programming with Object-capabilities in JavaScript Until now, browser-based security has been hell. The object-capability (ocap) model provides a simple and expressive alternative. Google's Caja project uses the latest JavaScript standard, EcmaScript 5, to support fine-grained safe mobile code, solving the secure mashup problem. Dr. SES -- Distributed Resilient Secure EcmaScript -- extends the ocap model cryptographically over the network, enabling RESTful composition of mutually suspicious web services. We show how to apply the expressiveness of object programming to the expression of security patterns, solving security problems normally thought to be difficult with simple elegant programs. Slides: http://soft.vub.ac.be/events/mobicrant_talks/talk1_ocaps_js.pdf Video: http://www.youtube.com/watch?v=w9hHHvhZ_HY Talk 2/2: Bringing Object-orientation to Security Programming Just as we should not expect our base programming language to provide all the data types we need, so we should not expect our security foundation to provide all the abstractions we need to express security policy. The answer to both is the same: We need foundations that provide simple abstraction mechanisms, which we use to build an open ended set of abstractions, which we then use to express policy. We show how to use EcmaScript 5 to enforce the security latent in object-oriented abstraction mechanisms: encapsulation, message-passing, polymorphism, and interposition. With these secured, we show how to build abstractions for confinement, rights amplification, transitive wrapping and revocation, and smart contracts. Slides: http://soft.vub.ac.be/events/mobicrant_talks/talk2_OO_security.pdf Video: http://www.youtube.com/watch?v=oBqeDYETXME -- You received this message because you are subscribed to the Google Groups AGERE! at SPLASH group. To post to this group, send email to agere-at-spl...@googlegroups.commailto:agere-at-spl...@googlegroups.com. To unsubscribe from this group, send email to agere-at-splash+unsubscr...@googlegroups.commailto:agere-at-splash%2bunsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/agere-at-splash?hl=en. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] new document
`+1`? Really? I seriously do not appreciate having my mail spammed in this
manner.
If you're offering an opinion on the article, try to say something specific
and relevant to those who might have skimmed it. Which parts interested you?
If you're referring to Sean's comment for recording the outreach events,
please consider moving it to another topic.
On Tue, Nov 8, 2011 at 3:17 PM, Julian Leviston jul...@leviston.net wrote:
+1
On 09/11/2011, at 6:30 AM, Kevin Driedger wrote:
+1 !!
]{evin ])riedger
On Tue, Nov 8, 2011 at 1:05 PM, Joel Healy joel.h.he...@gmail.com wrote:
+1
Joel Healy
On Tue, Nov 8, 2011 at 10:49 AM, DeNigris Sean s...@clipperadams.comwrote:
On Nov 7, 2011, at 6:08 PM, karl ramberg wrote:
http://www.vpri.org/pdf/tr2011004_steps11.pdf
It's so exciting to watch the project come along. I can't wait to
eventually play with it!
With every annual report, I think what a shame it is that there are so
many talks given about it (~20 this year) and so few (~3) are recorded.
Given the vital importance of this project, and all the work that must go
into preparing the talks, it seems like a great waste to share this
knowledge with only the few academics who happen to be at the various
conferences. I attend about 6 conferences a year and still feel like I'm
missing all the fun. Why doesn't VPRI just take the bull by the horns and
record them even if the conferences don't? Consumer video equipment is so
good now, it probably wouldn't cost anything but a few conversations - even
an iPhone video could work!
Sean
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] new document
On Tue, Nov 8, 2011 at 4:22 PM, David Barbour dmbarb...@gmail.com wrote: Can you elucidate the distinctions between Nile and Gezira? Nile is the programming language. Its syntax is a bit like Haskell. The high-level model of computation is a variation of Kahn process networks. The low-level part is a single-assignment, mathematics-oriented language for specifying the internal behavior of a process. Based on the (undocumented) code, I guess that Nile is more of a process model (queues, heaps, threads) You're looking at the implementation details of one of the Nile execution environments (i.e., runtimes), the multithreaded C-based one. The queues, threads, etc. are used for implementing the process network part of Nile on multithreaded CPUs. and Gezira is more of the rendering. Gezira is a 2D vector graphics renderer written in Nile. In that case, it may be Gezira I was thinking would compile well to shaders on a GPU. Certain parts of Gezira belong to the subset of Nile that could be efficiently executed on a GPU. OpenCL is certainly one approach to leveraging a GPGPU to a reasonable degree. Might be worth pursuing that route. But I've been surprised what can be done with just the rendering pipelines. Pure functional graphics convert to shaders + uniforms quite well. Certain stages of Gezira's rendering pipeline would not convert to shaders very well. Gezira covers different territory than, say, Pan, Vertigo, etc. None of Conal Elliot's pure functional graphics projects ever tried to perform, say, anti-aliased rasterization (AFAIK). They always relied on non-pure functional systems underneath to do the heavy lifting. Gezira, on the other hand, strives to do it all. And in a mostly functional way. The processes of Nile are side-effect free, with the exception of the final WriteToImage stage. Regards, Dan ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] new document
On Tue, Nov 8, 2011 at 4:54 PM, Dan Amelang daniel.amel...@gmail.comwrote: On Tue, Nov 8, 2011 at 4:22 PM, David Barbour dmbarb...@gmail.com wrote: Can you elucidate the distinctions between Nile and Gezira? Nile is the programming language. Its syntax is a bit like Haskell. The high-level model of computation is a variation of Kahn process networks. The low-level part is a single-assignment, mathematics-oriented language for specifying the internal behavior of a process. I've been reading through Nile and Gezira code and understand the model better at this point. It's basically pure functional stream processing, consuming and generating streams. I understand that `` generates one output, and `` seems to push something back onto the input stream for re-processing. Which Nile operators do you anticipate would translate poorly to shaders? I guess `zip` might be a problem. SortBy and pushback operators - at least if finite - could be modeled using shader global state, but that would be a bit of a hack (e.g. receive some sort of EOF indicator to emit final elements). Hmmm I think I'd be in trouble actually writing Nile code... I don't have a text editor with easy Unicode macros. Which do you use? None of Conal Elliot's pure functional graphics projects ever tried to perform, say, anti-aliased rasterization (AFAIK). They always relied on non-pure functional systems underneath to do the heavy lifting. I agree that Conal Elliott's focus has certainly been on composable, morphable, zoomable graphics models - primarily, everything that happens before rasterization. Anti-aliased rasterization can certainly be modeled in a purely functional system, or even via shaders in a graphics pipeline. Are you trying anything like sub-pixel AA? (seems a bit too system dependent for me, but it's an interesting subject.) My own interest in this: I've been seeking a good graphics model for reactive systems, i.e. rendering not just one frame, but managing incremental computations and state or resource maintenance for future frames. I don't think Gezira is the right answer for my goals, but I'll study and learn more from it. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] new document
there are people who read this list and website who may not feel qualified to participate much but none the less rely on them as a vital source of information Fellow lurker here. Thanks for pointing that out! Still, e-mails that say simply +1, me too, or I agree are a pain to receive on e-mail clients where they appear as a separate message, so it's usually courteous to avoid sending them to mailing lists. Back to the original topic, I wanted to drop a quick congrats to everyone on the amazing progress. It was a real treat to read this update, thanks for your hard work! Is there any chance I (someone with general programming knowledge, but without much intimacy with STEPS) could get Frank running on a virtual machine on OSX, or is that not worth attempting just yet? Cheers, Andrey ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] new document
Whether I use one or two thousand words to clothe my meaning is relevant?
I put just as much consideration into writing +1 as I did in writing this
email.
I could therefore also summarise your emails below as -1 for the entire
amount of meaning that it contains.
Allow me to expand on my +1:
I too agree that it would be lovely to be able to experience these events and
presentations via a video.
Julian
On 09/11/2011, at 10:32 AM, David Barbour wrote:
`+1`? Really? I seriously do not appreciate having my mail spammed in this
manner.
If you're offering an opinion on the article, try to say something specific
and relevant to those who might have skimmed it. Which parts interested you?
If you're referring to Sean's comment for recording the outreach events,
please consider moving it to another topic.
On Tue, Nov 8, 2011 at 3:17 PM, Julian Leviston jul...@leviston.net wrote:
+1
On 09/11/2011, at 6:30 AM, Kevin Driedger wrote:
+1 !!
]{evin ])riedger
On Tue, Nov 8, 2011 at 1:05 PM, Joel Healy joel.h.he...@gmail.com wrote:
+1
Joel Healy
On Tue, Nov 8, 2011 at 10:49 AM, DeNigris Sean s...@clipperadams.com wrote:
On Nov 7, 2011, at 6:08 PM, karl ramberg wrote:
http://www.vpri.org/pdf/tr2011004_steps11.pdf
It's so exciting to watch the project come along. I can't wait to eventually
play with it!
With every annual report, I think what a shame it is that there are so many
talks given about it (~20 this year) and so few (~3) are recorded. Given the
vital importance of this project, and all the work that must go into
preparing the talks, it seems like a great waste to share this knowledge
with only the few academics who happen to be at the various conferences. I
attend about 6 conferences a year and still feel like I'm missing all the
fun. Why doesn't VPRI just take the bull by the horns and record them even
if the conferences don't? Consumer video equipment is so good now, it
probably wouldn't cost anything but a few conversations - even an iPhone
video could work!
Sean
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] new document
On Tue, Nov 8, 2011 at 5:14 PM, Joel Healy joel.h.he...@gmail.com wrote:
Dave, I did not realize that you owned this topic. I wasn't even aware
that you started this topic. If I infringed on your intellectual property
rights, I apologize.
I have offered no pretense of owning the topic, and now I feel insulted by
your strawman apologies.
I would object to someone littering in my city's streets. That doesn't
require I own the streets, only that I use them.
If nobody else had followed your example, I would have said nothing. But
three people saying `+1` indicates a noisy, unproductive pattern that
should be discouraged, much like spam or chain letters.
As far as moving my comment to a new topic, that just doesn't seem
reasonable to me. Starting a new topic with I agree with what Sean said
in another topic seems to me to be a poor organizational structure.
I'm not asking you to behave foolishly.
Instead start another topic with a dedicated subject-line and something
like: Sean, in this other topic, suggests we record all VPRI outreach
events. BLOCKQUOTE. I agree and would like to see what can be done to
achieve this. If you are fishing for agreement, you could indicate Please
add your voice...
If I violated some list etiquette by expressing my opinion as +1, I do
sincerely apologize. Perhaps my opinion is of no value. I doubt that I
will offer any in the future, so there is no need to chastise me further.
Your opinion may be valuable. But `+1` is not very valuable, at least not
on this forum. On a mailing list `+1` is just noise, whereas
community-moderated fora (like Stack Exchange or Slash Dot) offer some
mechanism to express exactly this.
Regards,
Dave
On Tue, Nov 8, 2011 at 5:32 PM, David Barbour dmbarb...@gmail.com wrote:
`+1`? Really? I seriously do not appreciate having my mail spammed in
this manner.
If you're offering an opinion on the article, try to say something
specific and relevant to those who might have skimmed it. Which parts
interested you?
If you're referring to Sean's comment for recording the outreach events,
please consider moving it to another topic.
On Tue, Nov 8, 2011 at 3:17 PM, Julian Leviston jul...@leviston.netwrote:
+1
On 09/11/2011, at 6:30 AM, Kevin Driedger wrote:
+1 !!
]{evin ])riedger
On Tue, Nov 8, 2011 at 1:05 PM, Joel Healy joel.h.he...@gmail.comwrote:
+1
Joel Healy
On Tue, Nov 8, 2011 at 10:49 AM, DeNigris Sean
s...@clipperadams.comwrote:
On Nov 7, 2011, at 6:08 PM, karl ramberg wrote:
http://www.vpri.org/pdf/tr2011004_steps11.pdf
It's so exciting to watch the project come along. I can't wait to
eventually play with it!
With every annual report, I think what a shame it is that there are so
many talks given about it (~20 this year) and so few (~3) are recorded.
Given the vital importance of this project, and all the work that must go
into preparing the talks, it seems like a great waste to share this
knowledge with only the few academics who happen to be at the various
conferences. I attend about 6 conferences a year and still feel like I'm
missing all the fun. Why doesn't VPRI just take the bull by the horns and
record them even if the conferences don't? Consumer video equipment is so
good now, it probably wouldn't cost anything but a few conversations -
even
an iPhone video could work!
Sean
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] new document
+1 is a low-bandwidth way to express yes, let's explore what this person is
talking about some more because this is interesting.
If it's a problem, maybe the rule should be to place [+1] before the subject
line. But that's going to split the thread in lots of mail readers...
Especially when there's a strong polar dispute between people on squeak-dev,
this has worked really well in the short time I've been around.
One time I got in trouble for saying +1000. I guess I'm only allowed one.
:)
Casey
On Nov 8, 2011, at 5:14 PM, Joel Healy joel.h.he...@gmail.com wrote:
I started this +1 thing. It was indeed referring to Sean's comment (that is
why Sean's comment was quoted).
I thought about this post before I made it. Normally I would not spam a
thread with a me too comment, but in this case I thought that it was
important to let everyone know that there are people who read this list and
website who may not feel qualified to participate much but none the less rely
on them as a vital source of information.
Dave, I did not realize that you owned this topic. I wasn't even aware that
you started this topic. If I infringed on your intellectual property rights,
I apologize. As far as moving my comment to a new topic, that just doesn't
seem reasonable to me. Starting a new topic with I agree with what Sean
said in another topic seems to me to be a poor organizational structure.
If I violated some list etiquette by expressing my opinion as +1, I do
sincerely apologize. Perhaps my opinion is of no value. I doubt that I will
offer any in the future, so there is no need to chastise me further.
Regards,
Joel
On Tue, Nov 8, 2011 at 5:32 PM, David Barbour dmbarb...@gmail.com wrote:
`+1`? Really? I seriously do not appreciate having my mail spammed in this
manner.
If you're offering an opinion on the article, try to say something specific
and relevant to those who might have skimmed it. Which parts interested you?
If you're referring to Sean's comment for recording the outreach events,
please consider moving it to another topic.
On Tue, Nov 8, 2011 at 3:17 PM, Julian Leviston jul...@leviston.net wrote:
+1
On 09/11/2011, at 6:30 AM, Kevin Driedger wrote:
+1 !!
]{evin ])riedger
On Tue, Nov 8, 2011 at 1:05 PM, Joel Healy joel.h.he...@gmail.com wrote:
+1
Joel Healy
On Tue, Nov 8, 2011 at 10:49 AM, DeNigris Sean s...@clipperadams.com wrote:
On Nov 7, 2011, at 6:08 PM, karl ramberg wrote:
http://www.vpri.org/pdf/tr2011004_steps11.pdf
It's so exciting to watch the project come along. I can't wait to eventually
play with it!
With every annual report, I think what a shame it is that there are so many
talks given about it (~20 this year) and so few (~3) are recorded. Given the
vital importance of this project, and all the work that must go into
preparing the talks, it seems like a great waste to share this knowledge
with only the few academics who happen to be at the various conferences. I
attend about 6 conferences a year and still feel like I'm missing all the
fun. Why doesn't VPRI just take the bull by the horns and record them even
if the conferences don't? Consumer video equipment is so good now, it
probably wouldn't cost anything but a few conversations - even an iPhone
video could work!
Sean
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] New document, Appendix II Maru sample
See: http://code.google.com/r/kurts68-maru/ or the original repo: http://code.google.com/p/maru/ On 11/8/11 8:09 PM, David Girle wrote: I am trying to learn a little about Maru, so (jumping in the deep) I took the FFT code out of the Appendix II of tr2011004_steps.pdf and attempted to run it through Maru, taken from http://piumarta.com/software/maru/. I got successive errors, which I corrected by adding utility functions taken from boot.l , for: define-form define-function cadr concat-list quasiquote Unfortunately I am stuck with errors in quasiquote, assuming that such errors manifest as: eval.k: undefined variable: quasiquote Any guidance, other than start with baby steps ? Thanks, David ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Nile/Gezira (was: Re: +1 FTW)
Hi David, On Tue, Nov 8, 2011 at 6:23 PM, David Barbour dmbarb...@gmail.com wrote: The high-level model of computation is a variation of Kahn process networks. The low-level part is a single-assignment, mathematics-oriented language for specifying the internal behavior of a process. I've been reading through Nile and Gezira code and understand the model better at this point. It's basically pure functional stream processing, consuming and generating streams. I understand that `` generates one output, and `` seems to push something back onto the input stream for re-processing. Yes, you are correct. The spacial metaphor here is that streams flow from left to right, so x pushes x to the right, onto the tail of the output stream. x pushes (pulls? :) x to the left, onto the head of the input stream. Pipeline construction works this way too, e.g., ClipBeziers → Rasterize → ApplyTexture → WriteToImage . A bit silly, perhaps, but it works. Input prefixing is what I call this pushing of data onto the input stream, though I'm not set on that term. You used the term pushback, which I like, but the problem is that we're pushing onto the _front_ of the input stream, and pushfront just doesn't have the same ring :) Whatever the name, this feature is vital to writing expressive programs in Nile. It provides a recursion-like capability. For example, the DecomposeBeziers process successively decomposes Beziers until they are small enough to process. This is done by splitting the Bezier into two parts (à la De Casteljau), and pushing each sub-Bezier onto the input stream. I have never seen input prefixing in a stream-processing/dataflow language before. I could only find one passing reference in the literature, so unless someone points me to previous art, I'll be playing this up as an original contribution in my dissertation :) Which Nile operators do you anticipate would translate poorly to shaders? I guess `zip` might be a problem. SortBy and pushback operators - at least if finite - could be modeled using shader global state, but that would be a bit of a hack (e.g. receive some sort of EOF indicator to emit final elements). Hmmm Yes, this is the beginning of the difficulties. Just taking the input prefixing issue, it's problematic to model the unbounded input stream as global state. You have issues because of the finiteness of the global state, and because of the inefficiency of global write/read access in the shader (see GPU docs). And as I brought up before, even if one can get something to run on the GPU, that's very different from getting something to run much faster than on the CPU. Regarding your question about which processes would map poorly: the built-in Nile processes DupZip, SortBy, and Reverse (maybe DupCat, too). Many Gezira processes are a problem, such as ExpandSpans, CombineEdgeSamples, ClipBeziers, DecomposeBeziers, pretty much all of the processes in the file stroke.nl (pen stroking). There's probably more, these are off the top of my head. I think I'd be in trouble actually writing Nile code... I don't have a text editor with easy Unicode macros. Which do you use? I use vim. So I hit ctrl-v u2200 for ∀. Ideally, we'd have a Nile IDE with keyboard macros in addition to a little char map to click on (Bert built one for Frank). The theory behind using Unicode in Nile is that source code is read a lot more than it is written. So I'm willing to make code a bit harder to write for a payoff in readability. And if Nile becomes what it should be, one shouldn't have to write much code anyway. I agree that Conal Elliott's focus has certainly been on composable, morphable, zoomable graphics models I'm glad we agree...wait a second...when did I say the above? - primarily, everything that happens before rasterization. Ah, well, now I don't agree that his focus has been on everything that happens before rasterization. He's left out a lot. He's never taken on pen stroke approximation (which is vital for 2D vector graphics). I had to struggle a bit to come up with my functional approach to pen stroking (if I missed prior art, let me know!). He's never taken on, say, analytical geometry clipping. On top of that, there's a lot _after_ rasterization, and he doesn't addresses that territory much either. I like Conal's work, really. I read all his papers on functional graphics several years ago, and it probably subconsciously influenced my research. I'm just objecting to the idea that he covered very much functionality in the computer graphics space. I think he took on the easiest niche to model in a purely functional language. Anti-aliased rasterization can certainly be modeled in a purely functional system, Easier said than done, I think. Again, I struggled quite a bit to come up with the Gezira rasterizer (which is basically purely functional). I don't know of any previous anti-aliased rasterizer done in a purely functional style, do you? Pointers appreciated. You could
