Disqus - Latest Comments for nirvdrum

Re: Modeling RxDB in Rescript, Part 1

nirvdrum — Sat, 08 Jan 2022 23:27:50 -0000

Thanks for taking the time to write all of this up. When I was getting started with ReasonML I couldn't find much in way of real world applications with bindings to real libraries.

If it's not too much of a bother, it'd be helpful if you used GitHub links to specific SHAs. Where you've written "If you are doing your own bindings to libraries, I’ve found it’s also helpful to look at the typescript bindings, such as here", the linked TypeScript definition points at that project's master repo and the type definitions have since changed such that they no longer match the text in your article. But, it's pretty straightforward to see how to adapt for the latest RxDB release.

Re: The Delegation Challenge of Ruby 2.7

nirvdrum — Wed, 27 Nov 2019 14:53:25 -0000

The rubygems library is required by default in Ruby 2+ (1.9+?), so there's not much of a reason to not use its version API.

Re: How TruffleRuby's Startup Became Faster Than MRI

nirvdrum — Fri, 26 Apr 2019 02:36:08 -0000

Is the issue just with the post title? Maybe it could stand to say "VM Startup" instead of just "Startup". The article clearly delineates between VM and application startup though and makes the point that he was trying to cut down to the bare minimum to have a baseline. Given few thought it was possible, I think it's fine to declare his technical achievement and explain how it was accomplished.

Moreover, the post states:

In this blog post, I showed how we optimize VM startup in TruffleRuby. A related topic is application startup, that is how long it takes before running any useful work in your application, e.g., how long it takes for a Rails app until it can accept the first request. This of course depends a lot on the specific application.

Application startup is not really fast yet on TruffleRuby, and it is something we want to improve on. For instance, gem and bundle commands are significantly slower than on MRI currently.

Unless someone reads the title, maybe looks at the table, and then ignores all the text, I think the post is pretty grounded in its claims. It's a new baseline to build from and helps guide ongoing work.

Re: How TruffleRuby's Startup Became Faster Than MRI

nirvdrum — Thu, 25 Apr 2019 21:02:44 -0000

(Disclaimer: I work on TruffleRuby with Benoit.)

For the cases Benoit laid out, I think it's fair to say so. By making the loading of RubyGems lazy, he achieved the speedup you'd get with "--disable-gems" without the biggest side effect of that flag: the inability to use RubyGems without an explicit require of "rubygems".

If it turns out your script/application/etc. doesn't need RubyGems, with his approach you get the performance improvement and don't need to deal with passing the clunky "--disable-gems" flag around. Sure, devs can set it on the command-line, but I don't think many Ruby devs even know about it. I'd hazard to say it doesn't properly propagate to subprocesses in most Ruby code either.

So, running MRI with "--disable-gems" isn't exactly equivalent because there's a functional difference and an aesthetic difference. Naturally, MRI could adopt a similar lazy loading pattern as well. It may very well come back out on top in that case. Until then, I think the claim is valid.

As an aside, using Benoit's precise_time utility might be warranted to really reproduce results.

Re: Running Nextcloud in jail on FreeBSD

nirvdrum — Mon, 17 Jul 2017 00:15:05 -0000

Thanks for that tip. I was seeing the same issue with the PHP version conflict.

I found the memory cache also wasn't working. I had to run the following to get it to running:

# su -m www -c 'php /usr/local/www/apache24/data/nextcloud/occ config:system:set memcache.local --value="\OC\Memcache\Redis"'

Re: A Systematic Approach to Improving TruffleRuby Performance

nirvdrum — Thu, 15 Jun 2017 08:37:04 -0000

Getting comfortable with the graphs can take some time. Most of the nodes will relate back to Truffle & Graal, so you can always cross-reference them in a source checkout: http://github.com/graalvm/g...

The TruffleRuby change was fairly small. But you're right: I should've linked it somewhere! Here it is:
https://github.com/graalvm/...

Re: TruffleRuby on the Substrate VM - Kevin Menard's Weblog

nirvdrum — Mon, 20 Feb 2017 09:09:32 -0000

> Are all of these completely independent from the JIT, GC(s), AOT, etc that are in OpenJDK (in some cases 9+)? Or is there some cross-pollination?

The answer this really depends on the context in which you're using Truffle:

GC -- The JVM and the GraalVM use the same GC, while the SVM has a brand new GC.

JIT -- The JIT I was referring to is the one from the Graal compiler, which is shipped with the Graal VM. Using the new JVMCI feature in Java 9, you can add Graal as an extra compiler and use its JIT on a standard JVM (available in EA builds now).

AOT -- The AOT in Java 9 is based on Graal, but it's different than the static analysis performed by the SVM.

Instrumentation -- The profiler & debugger I mentioned are features of Truffle and apply to all the VMs. However, you won't get zero overhead instrumentation unless using Graal.

Polyglot -- Polyglot is a core feature of Truffle. It works on each of the supported VMs.

> Is this a temporary limitation that will be resolved later in development, or an inherent limitation that you can't see being overcome?

This is a core restriction and I don't see it being removed. To do so would considerably weaken the approach taken. However, it is possible someone writes an Java bytecode interpreter as a Truffle language, at which point you could use Truffle's polyglot features and AOT the interpreter with the SVM.

> One thing you didn't quite cover was open source. What are you thinking in that area?

Many of the technologies covered are already open source. Truffle, Graal, and TruffleRuby are open source. The SVM is a closed source distribution. As of today, there aren't any plans to open that up.

Re: TruffleRuby on the Substrate VM - Kevin Menard's Weblog

nirvdrum — Fri, 17 Feb 2017 13:15:03 -0000

It should be possible to do this with TruffleRuby on the SVM. We're shooting for 100% MRI compatibility. As we get further along with Rails, we'll be looking at the preloaders for sure.

Re: Official Linux Packages for Sync Now Available

nirvdrum — Thu, 18 Feb 2016 15:56:02 -0000

Can you make the code sections raw text please? They currently use smart quoting and as such can't just be copied and pasted into a terminal. Those special characters need to be translated back to their ASCII equivalents.

Re: Mad Max Game And Custom Xbox One Console Giveaway

nirvdrum — Mon, 31 Aug 2015 10:57:53 -0000

'93 Ford Escort

Re: UPDATED: The Witcher 3: Wild Hunt Collector’s Edition Giveaway

nirvdrum — Thu, 21 May 2015 21:47:38 -0000

Brute force combat.

Re: UPDATE: Mortal Kombat X and Fight Pad Giveaway

nirvdrum — Thu, 16 Apr 2015 22:08:02 -0000

Sub Zero. He was fantastic in the first movie.

Re: nirvdrum's Weblog :: Open Sourcing a Failed Startup

nirvdrum — Fri, 28 Nov 2014 21:58:18 -0000

Thanks, Tom.

Re: nirvdrum's Weblog :: Open Sourcing a Failed Startup

nirvdrum — Sat, 22 Nov 2014 10:24:45 -0000

Well, this one is complicated because I created the company in order to further Web Consistency Testing. I'd have loved if that technology would continue to evolve without me. And it may very well, since Mogotest wasn't the only company in this space, but Mogotest was something of a reference implementation. If I could have open-sourced it, it would have helped satisfy one of my initial goals. Oh well.

Re: nirvdrum's Weblog :: Open Sourcing a Failed Startup

nirvdrum — Sat, 22 Nov 2014 10:22:41 -0000

That's a tough call. Being service-oriented from the outset would have helped, I think. It started as a Rails prototype to do the whole MVP thing and then grew into a monolithic Rails app. New features did end up being services, but I couldn't justify rewriting working code just to have a cleaner separation.

Maybe open-sourcing everything from the outset would have helped. But it'd have limited my options in other ways, too. E.g., I would have likely continued trying to make jQuery UI work rather than go with the far simpler ExtJS. That's just a business trade-off. I think I still would have preferred to optimize value for current customers over trying to ensure open-sourcing everything would be a breeze should I fail.

Re: nirvdrum's Weblog :: Open Sourcing a Failed Startup

nirvdrum — Fri, 21 Nov 2014 22:14:00 -0000

Thanks. More time for Rubber now, right? :-P

Re: nirvdrum's Weblog :: Open Sourcing a Failed Startup

nirvdrum — Fri, 21 Nov 2014 21:05:44 -0000

Well, the campaign is over. But, you're right, that was a hole in it. The idea was more that I'd give you a license to embed in your own product without having to worry if I went AGPL on the whole thing. But, I kinda just threw it there as a pricing experiment of sorts. No one bit, so we'll never learn how that would've played out.

Re: nirvdrum's Weblog :: Open Sourcing a Failed Startup

nirvdrum — Fri, 21 Nov 2014 19:50:21 -0000

It's an interesting idea. If you have a group of people in mind, feel free to email me.

Re: nirvdrum's Weblog :: Open Sourcing a Failed Startup

nirvdrum — Fri, 21 Nov 2014 19:49:39 -0000

I found the process a bit cumbersome. After spending the first whole day on it, I really began questioning why I was spending the time. At the end of that first day, I started writing this post. As I was writing the post, it became clear that this didn't really make much sense. But, I pushed ahead anyway. At the end of it all, I had something I couldn't run and I wasn't all that eager to start rewriting pieces.

I guess for me, I had already mentally moved on. So, revisiting the code and giving up even more for the project just was a drag.

Re: nirvdrum's Weblog :: Open Sourcing a Failed Startup

nirvdrum — Fri, 21 Nov 2014 18:05:31 -0000

Yeah, it's a tough call. I see value in both open source and closed source. Being open source can be a distraction. And a lot of companies when they're banging out that initial prototype cut a lot of corners. You need to decide what's best for you.

But, as I mentioned, I don't see any inherent value in code being public, either. A code dump generally is useless to me. I find a lot of value in open source projects. But the dumping ground that is GitHub for every little project doesn't seem to be appreciably advancing humanity in any perceptible way.

Re: nirvdrum's Weblog :: Open Sourcing a Failed Startup

nirvdrum — Fri, 21 Nov 2014 14:31:54 -0000

Thanks. It was more frustrating than anything else. Losing money sucks. Feeling taken advantage of sucks. Feeling inadequate sucks. But, in the grand scheme of things, running Mogotest afforded me a lot of flexibility in finding my next position. The optimization and correctness work I did in JRuby over the past few years was the perfect opening into Oracle Labs and is something I wouldn't have been able to do otherwise.

Re: nirvdrum's Weblog :: Open Sourcing a Failed Startup

nirvdrum — Fri, 21 Nov 2014 14:09:39 -0000

Thanks!

Re: nirvdrum's Weblog :: Open Sourcing a Failed Startup

nirvdrum — Fri, 21 Nov 2014 13:44:58 -0000

Well, I did precisely that on IndieGogo. Granted, I didn't got nuts
advertising it. But I privately messaged a lot of the relevant players
in the space, our customers, and community members.

Re: Graylog2 - Manage Nginx Combined Syslog log messages

nirvdrum — Tue, 28 Oct 2014 17:39:55 -0000

Would it be better if these looked at the facility rather than running a regexp against every syslog message? Or does that not really improve performance?

Re: Guarding with arrays

nirvdrum — Tue, 06 May 2014 11:03:05 -0000

In this case that would work, for sure. I expanded it to show the
general case (any ref, which may be nil) with an optional fallback as
the null object ([] in this case). Apologies if that wasn't clear.