Gitless has no staging area

I frequently use git add -p to stage chunks of diffs, so that I can make separate commits of unrelated changes in a single file. I would miss that feature greatly.

I’ll agree that the push to Apache seems to be coming from a few unnamed corporates rather than “the LLVM community” as a whole. But Theo is being quite unfair with the assertion that proper signoff won’t be sought from contributors. As Chris Lattner says “Here we are discussing what the best end game is – not the logistics of how to get from here to there.”

Step 1: decide to investigate changing license

Step 2: decide what license to change to <– we are here

Step 3: decide a plan for getting sign-off from contributors on the licensing change, and dealing with missing contributors or those who do not want to support the license move (e.g. rewrite or revert the change)

Step 4: enact the plan

I’ve been through a lot of todo management tools (even wrote my own minimal solution) and I have to say my favourite todo tool is taskpaper.vim. It’s easy to overlook it as being just a syntax file for the taskpaper format, but actually the few keybindings it provides to mark tasks as done and archiving them are all you need. Key features it offers that are surprisingly hard to find elsewhere:

• Simple text-based format
• Ability to keep notes alongside a given task
• Ability to easily have different task lists for different projects
• Nested tasks

[Comment removed by author]

I feel that having Cloudflare host a subset of DNS Linode servers would be great to add extra resiliency. Putting all DNS in the hands of an external provider and retiring Linode’s own servers seems a shame though.

Inspired by the weekly threads here on lobste.rs and in the Rust community, I’ve actually started a “What are you working on” thread on the lowRISC mailing list. lowRISC is our project to produce a completely open source System on Chip implementing the RISC-V architecture.

Last week I was at DAC, talking to various vendors and delivering a section of the RISC-V tutorial. Our section made use of the untethered lowRISC release and associated documentation.

Thanks to hard work from my colleague Wei, lowRISC contributor Stefan, and others we are now approaching the point where we can make a new code release including trace debug support. The previous untethered release still had support for the host-target interface (HTIF) in the kernel but had a small program to map the HTIF calls to underlying hardware peripherals (e.g. UART, SD card). This week, I want to look at ensuring we have a kernel that properly supports communicating with the platform peripherals directly.

I wonder how many of these repositories aren’t software (e.g. dotfiles or other config, websites). You could of course put a license on these (though tracking provenance for snippets in your vimrc might be a pain), but I can understand why most wouldn’t bother.

I take day-by-day notes in a markdown file in vim (simple chronological order). I keep my todo-list in Taskpaper format using the taskpaper.vim plugin, and my preferred method of working involves adding lots of notes under each task I work.

“It’s the world’s tiniest open source violin”

https://xkcd.com/743/

That’s great news, I really hope RISC-V and lowRISC projects will be successful. I know this is premature, but taking the opportunity to ask when can we expect dev boards to reach general availability?

Hey, that’s awesome. I’m on the RISC-V team at Berkeley, and we’re trying to move towards un-tethered systems as well. I won’t be able to attend the RISC-V workshop, but some of the other students will. I think it would be great if you could share some of your experience with them so we know what pitfalls to avoid.

So far, we have most of the required hardware features like MMIO and a hardware device tree implemented. From here on, it’s mostly implementing peripherals and updating all the software.

Nice! Any insight into lowRISC vesus the work that the Open Proscessor Foundation is doing with J2/SuperH?

As ever, I try to highlight interesting developments from the LLVM project in LLVM Weekly (just hit issue 100). Sign up if you’re interested in keeping track of future LLD dev.

Mostly chiptunes on the excellent Rainwave internet radio station http://chiptune.rainwave.cc/

So have us in the lowRISC project. We have a range of project ideas across many languages and different levels of the hw/sw stack at http://www.lowrisc.org/docs/gsoc-2015-ideas/

Should be a great summer!

I’m very excited that lowRISC has been accepted to take part. We’re working with a range of projects in the FOSS and OSHW community to provide what I think is a pleasingly broad set of project ideas. You can help on our mission to produce a fully open source SoC while getting paid to hack in Python, Go, Javascript, C, C++, Chisel, or SystemVerilog on projects at any level of the hw/sw stack.

Surprisingly, some organisations who have been taking part for years didn’t make the cut this time. Most notably, Mozilla weren’t accepted. No Blender, Tor, Xen, or Linux Foundation this year either.

“Take care when publishing a crate, because a publish is permanent. The version can never be overwritten, and the code cannot be deleted. There is no limit to the number of versions which can be published, however.”

This is good news!

This week, I’ve been trying to get back on the horse. I didn’t post an update last week, not because I didn’t do anything, but because I just didn’t feel like talking.

This has been an interesting week though and I’m finally ready to start talking about my new project.

I haven’t done much with Open Dylan as I’ve been busy with some other stuff. I did, however, start the creation of a Homebrew tap for Dylan that will work once the 2014.1 release is out. I also added some very basic bash completion for the Dylan compiler. And, speaking of the 2014.1 release, I’ve decided to do the release around the start of December, on whatever platforms work at the time. Anyone interested in non-OS X platforms should get in touch to do builds, testing and fixes.

For my work, I’m moving to a new project for the client this week. I’ll be working, in part, to track down some performance issues in their code base. This is all emscripten related, and some of the issues may require me to use IRHydra2 to track some issues under V8. This should be pretty interesting and a good challenge. I look forward to learning a lot.

My new project is something that I’ve only talked about in a relatively private setting so far in any detail. I call it Debug Workbench and it is a programmable, extensible visual debugger. I’ll start talking about real details fairly soon, but if you’re interested, follow along on Twitter at @DebugWorkbench.

Debug Workbench is being built using Atom Shell to provide the user interface and currently with LLDB as the debugger backend (but this is going to be pluggable). The current target is to deal with native debugging (since I’m using LLDB), but I may expand in the future.

One of the things that makes this different from existing debuggers is that it uses plug-ins to extend the system. Once you have the ability to set breakpoints that can execute scripts, a lot of magic things can happen.

One example of this could be a performance advisor plug-in that watches for common API mis-usage, like calling regcomp with the same regular expression many times, or calling write with small buffers frequently.

Another, much more involved use case would be an extension that watches for calls to accept, bind, connect and reads data from the debugee process and emits events to indicate (to other plug-ins) what is happening in terms of network activity. From there, another plug-in could start a packet capture and monitor the actual network traffic generated by the program being debugged. This is why I wrote about packet capture and dissection from within JavaScript recently.

By using Atom Shell, I have full access to a huge ecosystem of useful code and capabilities. Want to use D3 to graph some data from your program? Want to use WebAudio to play back an audio buffer or look at a spectrum analysis of the audio buffer?

The goal here is to open up a whole new world of debugging tools and ways to interact with your running program and this is something that I’m pretty excited about. This has been taking almost every spare minute of my time for the last few weeks and the pieces are starting to come together.

I’m not entirely sure of the funding model for this yet. I want to keep as much open source as I can, but I recognize that this will need full-time efforts from some people to make it come true. To that end, I’m looking at doing a crowd-funding or looking for corporate sponsors.

I don’t want to talk about this on other websites yet though as I want to have a better working prototype and some screenshots first.

Until next week!

I feel the same way. I’ll often compose a tweet, spend a minute or two trying to rephrase it to fit in 140 chars, and then give up when I realize it’s lost its meaning in “translation”.

Customers tweet at my company account from time to time asking questions but usually all I can do is reply “send us a detailed e-mail and we’ll get back to you” because it’s such a useless platform for dialog. It’s mostly just a platform for shouting things and slacktivism these days.

I still don’t get why Twitter is holding onto the 140 character limit, making the vast majority of its users deal with a limitation imposed by an outdated delivery mechanism that I would guess a very small minority of its users still use.

Twitter’s API could even support long tweets while still keeping backwards compatibility. Make the first ~130 characters the actual tweet, and stuff the rest of the text in an entity. Old clients just show the first ~130 chars but with some kind of indication that it’s truncated, but Twitter’s website and newer clients with entity support strip out that indication, load the rest of the text in the entity, and display it all together as one long tweet.

This weekend I was in Munich for the OpenRISC conference. I presented the lowRISC project, in particular our plans for tagged memory and ‘Minion’ cores for I/O. My slides are available here. I’ve completed the tagged memory part of our whitepaper, we just need to work in some more detail on the Minion cores and that should hopefully be ready for internal review in the next week or so, then put out soon after.

I hope to find some time to pick back up work on Pyland this week.