<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 3, 2013 at 3:13 PM, B B <span dir="ltr"><<a href="mailto:blackbox.dev.ml@gmail.com" target="_blank">blackbox.dev.ml@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><br></div></blockquote></div><div>I think GHCJS should be able to compile all Haskell code in GHC, but we haven't tested this yet. The tricky bit is probably getting foreign code work, and creating a working installation that includes all other things, like libraries and a package database. Usually, GHCi loads object files for the libraries when running Haskell code. Obviously you can't run machine code with JavaScript, so you'd have to find a way around it. GHCJS includes an IO layer, which can be used to set up a virtual filesystem [2], but the API is far from finished.</div>
</div></div></div></blockquote></div><div>Nice to hear that - we are concidering using GHCJS heavly in our project. We dont have many people and this is free-time "driven" project for now, but we would love to cooperate with you - help with GHCJS development and work together to make it suitable for the project we are working on.</div>
<div class="im">
<div><span style="color:rgb(34,34,34)"></span></div></div></div></div></div></blockquote><div><br></div><div style>Great, if you want to help or discuss, you can come to #ghcjs on freenode.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><div><span style="color:rgb(34,34,34)"> </span><br></div></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><div></div></div><div>This is not exactly the kind of thing I'm talking about. </div><div>Think about something like matlab simulink or labview - functions are representaed by "nodes" (rectangles) connected with other functions by lines. Lines are "sending data" between these nodes. </div>
</div></div></div></blockquote><div><br></div><div style>I think it's possible to "trap" function application and show inputs and outputs that way, but it might be tricky (maybe some patching required). Also the generated optimized code can be quite different from the original Haskell. There is lots of inlining, let floating and specialization, and all functions that use typeclasses get extra parameters for the dictionaries for example, so i guess trying to visualize everything automatically will not give you the results you're after.</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>So user is connecting these blocks - each block is like a function application on data - so adding a block is like adding a new line in Haskell .hs file. We want user to be able to interactively add such nodes (apply further functions on already processed and cached data - every "node" caches processed data) and process the data further - If I didn't explained this simple enought, I will try harder. Such thing needs something like client side interpreter I think ...</div>
</div></div></div></blockquote><div><br></div><div style>You could let the user edit functions, then call back to the server and get back graph nodes (and the code to run them of course), which could show the name and the correct number of inputs. Actually connecting them would require a typechecker though (and changing one connection can of course make other connections invalid), perhaps through a server callback.</div>
<div style><br></div><div style>If you want to work with cached data, you probably want to use some special thing to connect the functions, since Haskell code generally does not do that. Perhaps FRP can be an inspiration here, where your graph editor wraps pure Haskell functions (written by the user) in behaviours, and changing values or behaviours propagates changes through the FRP network.</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>When we have the SELinux sandbox working, I plan to work on this again, so that users can enter/compile their own code.<br></div><div><br></div></div></div></div></blockquote><div><br></div></div><div>When do you plan roughtly to release it? We are strongly interested in testing and using it :) </div>
</div></div></div>
</blockquote></div><br></div><div class="gmail_extra" style>The current code is already on github, but it does not quite work yet (and using it is not recommended until we are confident in the security of the sandbox). Daniil will probably blog about it soon, and we should have a public beta within a month.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>luite</div><div class="gmail_extra" style><br></div></div>