Search Results: "bjorn"

20 September 2023

Joey Hess: Haskell webassembly in the browser

live demo As far as I know this is the first Haskell program compiled to Webassembly (WASM) with mainline ghc and using the browser DOM. ghc's WASM backend is solid, but it only provides very low-level FFI bindings when used in the browser. Ints and pointers to WASM memory. (See here for details and for instructions on getting the ghc WASM toolchain I used.) I imagine that in the future, WASM code will interface with the DOM by using a WASI "world" that defines a complete API (and browsers won't include Javascript engines anymore). But currently, WASM can't do anything in a browser without calling back to Javascript. For this project, I needed 63 lines of (reusable) javascript (here). Plus another 18 to bootstrap running the WASM program (here). (Also browser_wasi_shim) But let's start with the Haskell code. A simple program to pop up an alert in the browser looks like this:
 -# LANGUAGE OverloadedStrings #- 
import Wasmjsbridge
foreign export ccall hello :: IO ()
hello :: IO ()
hello = do
    alert <- get_js_object_method "window" "alert"
    call_js_function_ByteString_Void alert "hello, world!"
A larger program that draws on the canvas and generated the image above is here. The Haskell side of the FFI interface is a bunch of fairly mechanical functions like this:
foreign import ccall unsafe "call_js_function_string_void"
    _call_js_function_string_void :: Int -> CString -> Int -> IO ()
call_js_function_ByteString_Void :: JSFunction -> B.ByteString -> IO ()
call_js_function_ByteString_Void (JSFunction n) b =
      BU.unsafeUseAsCStringLen b $ \(buf, len) ->
                _call_js_function_string_void n buf len
Many more would need to be added, or generated, to continue down this path to complete coverage of all data types. All in all it's 64 lines of code so far (here). Also a C shim is needed, that imports from WASI modules and provides C functions that are used by the Haskell FFI. It looks like this:
void _call_js_function_string_void(uint32_t fn, uint8_t *buf, uint32_t len) __attribute__((
void call_js_function_string_void(uint32_t fn, uint8_t *buf, uint32_t len)  
        _call_js_function_string_void(fn, buf, len);
Another 64 lines of code for that (here). I found this pattern in Joachim Breitner's haskell-on-fastly and copied it rather blindly. Finally, the Javascript that gets run for that is:
call_js_function_string_void(n, b, sz)  
    const fn = globalThis.wasmjsbridge_functionmap.get(n);
    const buffer = globalThis.wasmjsbridge_exports.memory.buffer;
    fn(decoder.decode(new Uint8Array(buffer, b, sz)));
Notice that this gets an identifier representing the javascript function to run, which might be any method of any object. It looks it up in a map and runs it. And the ByteString that got passed from Haskell has to be decoded to a javascript string. In the Haskell program above, the function is document.alert. Why not pass a ByteString with that through the FFI? Well, you could. But then it would have to eval it. That would make running WASM in the browser be evaling Javascript every time it calls a function. That does not seem like a good idea if the goal is speed. GHC's javascript backend does use Javascript FFI snippets like that, but there they get pasted into the generated Javascript hairball, so no eval is needed. So my code has things like get_js_object_method that look up things like Javascript functions and generate identifiers. It also has this:
call_js_function_ByteString_Object :: JSFunction -> B.ByteString -> IO JSObject
Which can be used to call things like document.getElementById that return a javascript object:
getElementById <- get_js_object_method (JSObjectName "document") "getElementById"
canvas <- call_js_function_ByteString_Object getElementById "myCanvas"
Here's the Javascript called by get_js_object_method. It generates a Javascript function that will be used to call the desired method of the object, and allocates an identifier for it, and returns that to the caller.
get_js_objectname_method(ob, osz, nb, nsz)  
    const buffer = globalThis.wasmjsbridge_exports.memory.buffer;
    const objname = decoder.decode(new Uint8Array(buffer, ob, osz));
    const funcname = decoder.decode(new Uint8Array(buffer, nb, nsz));
    const func = function (...args)   return globalThis[objname][funcname](...args)  ;
    const n = globalThis.wasmjsbridge_counter + 1;
    globalThis.wasmjsbridge_counter = n;
    globalThis.wasmjsbridge_functionmap.set(n, func);
    return n;
This does mean that every time a Javascript function id is looked up, some more memory is used on the Javascript side. For more serious uses of this, something would need to be done about that. Lots of other stuff like object value getting and setting is also not implemented, there's no support yet for callbacks, and so on. Still, I'm happy where this has gotten to after 12 hours of work on it. I might release the reusable parts of this as a Haskell library, although it seems likely that ongoing development of ghc will make it obsolete. In the meantime, clone the git repo to have a play with it.
This blog post was sponsored by unqueued on Patreon.

27 March 2012

Wouter Verhelst: Bjorn Monnens on Debian

If this were twitter (and if I had a twitter account, which I don't), this post would start with "RT". As it is, you'll have to make do with this link: Bjorn Monnens on why he chose Debian testing over Fedora.
This weekend I switched again to Debian 6 testing as this is also Gnome 3. I had to do the same stuff as for Fedora but I noticed already that it s much more stable and it is also much faster than Fedora. Boot is really a difference of +30 seconds.
Go team! (with apologies to those who read this blog through Planet Grep, as Bjorn is there too)

8 October 2008

Wouter Verhelst: Why I don't want an iSomething, part II

Bjorn mentions that he doesn't want the nokia internet tablet, because it doesn't have a phone and he doesn't want to carry two devices with him. portable media player Bottom left, my portable media player. 4G solid-state storage, plays movies (the display shows a scene from Star Trek: Deep Space Nine that I converted from DVD), audio, FM radio, and after a firmware update can do games and some random applications. Does bluetooth. Does not do phone calls. Upper right, my cell phone. A simple Nokia 6021. Does bluetooth, makes phone calls, and (as the display somewhat shows) can do calendaring, too. With SyncML, I can synchronize it with my laptop. Together, they perform anything I'd possibly want from a smartphone (and don't anyone tell me 'SSH', because doing ssh on any screen smaller than, 7" and without decent keyboard is laughable). Together, they're smaller and weigh less than a smartphone. Together, they're less expensive than a smartphone ( 125 for the phone, 85 for the portable media player). Why does anyone buy a smartphone?

17 December 2007

Frans Pop: aptitude upload not something to be proud of

Sometimes it is extremely tempting to wave a huge, heavy, spiked cluebat around. Today I've decided to give in to this temptation. The case in point is the upload today by their maintainer of first cwidget and later aptitude. The fact that the maintainer blogged about both uploads probably means that he's pretty happy about it. Unfortunately I, and people in the Debian release team, were less than amused. Reason is that the uploads set back a complex transition of apt and related packages by at least a week. This is a transition we'd already been following and trying to get into testing for over a month and which was finally as good as ready to go. So what was so wrong about these uploads and what could (should?) the maintainer have done? First of all he should have realized that aptitude has become a rather central package in Debian with strong ties to apt and thus to a lot of other packages. Second, he should have checked whether his previous uploads had already migrated to testing and, if not, why not. The excellent testing migration page for aptitude (which is linked from its PTS page clearly shows that it is tied in a transition involving about a 100 packages in total. The right thing to do in such a case is to contact the release team (preferably at the debian-release mailing list, or at #debian-release). This would undoubtedly have resulted in a request to delay the uploads a few days until the transition had finished. Unfortunately that did not happen and cwidget was uploaded. Because of an ABI bump it ended up in NEW. Because of the transition I did a quick request to Joerg Jaspert to please delay accepting cwidget until the transition was over. But then a third mistake, and arguably the most serious one of the lot, was made. aptitude was uploaded for i386, built against the cwidget library which had not yet been accepted into unstable. Basically that means that an uninstallable package was uploaded. And of course it meant that at that point all efforts to finalize the transition for apt went down the drain. Some alternatives were discussed on how to deal with the new situation, including a sourcefull upload of the previous version of aptitude, but in the end it was decided to just accept the delay as one of the more annoying facts of life and instead ask Joerg to accept cwidget from NEW. In the end the damage may be a bit less than a week if the buildds cooperate (which they probably won't with cwidget still stuck at the wrong priority) and the RMs decide to force things. I sincerely hope that this story will make all Debian Developers and Debian Maintainers a bit more aware of the broader context and consequences of uploads. Oh, as I'm not an RM myself you may wonder what my interest is in this. We've got this great new feature in Debian Installer that adds support for multiple CDs during an installation (a feature that was lost with the integration of base-installer into D-I). However, we can only upload the relevant D-I component after apt 0.7.9 has reached testing...

27 July 2007

Holger Levsen: blog recycling

This makes me smile.

And even the DM GR makes me smile, as I hope it will pass :-) Stefano summarized nicely why I think DMs are a good thing.

And "as usual" Joey came up with a new interesting thought: The interesting thing to consider is, if this vote fails, how can the bug be fixed without another vote?

Clint Adams: Gozando hasta que salga el sol

This makes me smile. The DM GR and the discussion surround it do not make me smile.

8 April 2007

Ingo Juergensmann: The big Debian day

Today - as many of you have already noticed - is/was a big day for Debian:

Well, I could add another topic:

In a more detailed view:
Sam Hocevar won the DPL election
Congrats to Sam! I can agree with most of the points he made in his DPL platform, e.g. a sexier website, sexier distribution, remaing the universal OS, etc.
sexier website: Really, the current design of Debians website is awful. It's really something back from the 90s. Bad look, bad design and stuff you're looking for is difficult to find, because it's badly structured and stuff is spread all over the place. I think, it would be good to have some decent CMS and some good designers/graphic artists - a good package maintainier doesn't make a good webdesigner.
sexier distribution: Many people are using Ubuntu because they're desktop users. The current release cycles are way too long and drive people away from Debian. It's a different matter, of course, for servers or managed systems like Terminal Servers or such. Those are fine with longer release cycles. Splitting up the release in some core and sub releases is a quite common proposal. Yes, this split is difficult, but I think it's the way to go.
remaing the universal OS: As of the release of Etch, Debian became the no-more-universal OS - just because m68k wasn't released for obscure reasons. I'm a great m68k user and now I'm left behind by Debian with the problem that my pet arch is not supported anymore. Running testing/unstable is not an option for m68k IMHO. Because the m68k porters didn't come up with an alternative release plan so far, I think it's the best to shutdown my 3 m68k machines - all of them are m68k buildds - within the next weeks or months. They're producing (well, some little) heat, some disturbing noise and consume a lot of power of course. Currently I accept those drawbacks in order to help the m68k port by donating CPU power running some buildds for about 7 years now. I've spent much more money on this purpose - not only for paying the electricity bills - for phone calls to get crashed remote machines rebooted, sending replacement parts for other buildds or even driving by car to bring machines or other parts to other persons (like to Michael Schmitz or accel boards to the Netherlands for porting stuff. Anyway, I will happily reactivate the machines when it's up to make a new release for the m68k architecture again! :)

Some other point Sam mentioned in his platform is this:
There are very useful services around, such as, or I cannot understand why they are not Debian services.

I already had a conversation with Sam about this in which I expressed my general intention to develop at least Buildd.Net beyond its current state - it's quite frustrating for me to see Buildd.Net being stuck in development just because I've no more time and skill to develop Buildd.Net further. Sadly, my call for help wasn't as successful as I wanted. Only two persons wanted to help: faw and joey - and both are quite busy with other stuff.
Apparently, Buildd.Net will most likely suffer from shutting down my m68ks due to the missing m68k Etch release as well, because it was always a frontend to my m68k buildds in my eyes. All other stuff on Buildd.Net is just a nice addition to that. And when I don't operate m68k buildds on a daily basis, it's obvious that I won't invest much more time into the development of Buildd.Net. This is already true for the past year where I haven't found the time to fix some serious problems in the backend scripts and database of Buildd.Net, which basically breaks (source and therefor ptracker.cgi(example) as well. I even haven't found the time to setup trac and svn again after the move to the new server during last autumn.
Erm, anyway.. back to the topic: I wish Sam the best for his period - but I don't think that he can make a big change. I doubt in general that any DPL is able to push big changes in Debian. One reason for this is the short period of just one year. Another reason is that many DDs won't let big changes to be made.

21 October 2006

Steve Langasek: Gotta make the donuts

Hmm, let's see if we can turn britney hint file comments into a blog entry... The apache 2.2 transition is coming along rather well. This is good news, giving us a shot at including a version of apache2 in etch with support for files > 2GB in size. Even though pervasive LFS support has been a goal in Debian since before sarge, when a big part of the interface your library exports to users deals with files it gets tricky to switch on LFS support because of ABI changes. After tagging for removal a number of apache2 modules with unrelated build problems, that leaves us with these issues blocking the transition: Nothing that a medium-sized hammer can't take care of... The release managers have also issued a statement about where we stand now for non-free firmware in etch. I'm sure this isn't anything close to the last word on the subject, but hopefully it will be enough to let us begin moving forward again instead of spinning our wheels on vote discussions.

19 October 2006

Steve Langasek: Juggling Cats

The one thing about agreeing to dedicate my time exclusively to Debian for a month is that it means there are loose ends that had to be tied up first -- loose ends that in my case took until October 11th to tie up, leaving me no time to keep up on Debian in the meanwhile... But hey, it only took me until Saturday to get a handle on my email again (more or less), and until Monday to clean up the list of RC bugs so that it pretty accurately represents what we need to finish up for the release. And hey, it's really not too bad, when you consider that of the 299 RC bugs listed on as applying to etch, only 104 of them are more than 10 days old, which means we can expect a pretty sharp decline in this count as our maintainers diligently fix the hidden RC bugs that dunc-bank have been helpfully reporting for us. :) And of those 104 older RC bugs, about 10% or so are already fixed in unstable as part of one of two transitions: the Xorg 7.1 transition and the apache 2.2 transition, so that's where I'm focusing my attention right now -- along with tackling the "low-hanging" bugs, the ones on my own packages... There are other transitions we still need to pay attention to, such as ghc6 (fixes wrong code generation problems on alpha), libraw1394 (lib transition that blocks a few other RC bugfixes), and linux-2.6 (newest kernel wanted for best upstream security and hardware support), but other than that, we're pretty darn close to having the right set of packages for release. The freeze is looking closer every day!

30 June 2006

Andreas Barth: On the pain of having so many architectures

Now is a time where I feel the pain of supporting so many architectures again. I'm now not speaking about m68k, because that doesn't hurt the release team at all any more. I however speak about a dependency chain I blogged already about recently, which holds up removal of xorg-x11 (6.9) from testing. Now, we look at getting newer packages in. We basically need to update rhythmbox. However, rhythmbox is not yet build on sparc, because there some build-dependencies are not yet uptodate on sparc. Rhythmbox is not the only issue, it's indirect dependency qt4-x11 FTBFS on hppa with "*** glibc detected *** free(): invalid pointer: 0x00142838 ***". More issues to come, on another hint I'm trying to get resolved, I detected an ICE (Internal Compiler Error) on ia64. In sum, there is really some arch-specific pain available right now. I'm not happy with that at all.

24 January 2006

Steve Kemp: Take me to that place I love

I have resolved to actually sit down and keep working on GNUMP3d until I have:
  • Refactored all incoming request parsing.
  • Updated all HTML templates to use the HTML::Template module.
  • Reorganised each available theme such that it may be easily displayed in multiple languages.
Each of these things has needed doing for a while, but I find it hard to be enthusiastic. Still the addition of new test cases should make it more interesting, and is liable to make the code correct too.
It looks like the current version of xen-tools is moving to testing today which means I should be able to upload a new revision tonight. Maybe I should stop obsessing over the migration to testing of packages? I’m not too sure if I’m helping people by trying to make sure there is a “recent” version of each package in Testing before uploading to unstable. (Mostly because I don’t run testing, never have, and know nobody locally who has told me they do.)
There is a new project interested in group-maintainership of Debian games: details here. I uploaded two packages to the shared SVN repository, but otherwise haven’t done anything. It seems like lots of people have grandiose ambitions, I guess we’ll see how it works out.