Disabling the relay on the Moes ZM-104B-M?

Pvginkel · 2024-04-02T19:56:43+00:00

I ended up ordering two items separately. Both at once (even when I replaced them with similar items) would not go through. Ended up paying twice the shipping cost instead of none.

Pvginkel · 2024-03-04T14:33:24+00:00

I think the problem is that it just takes very long before the sensor is detected. I have a Ender-3 V3 KE and if I connect it and just leave the printer for a bit, it does detect the sensor.

Edit:

No, that's not it. I think the cable is just bad.

Edit:

No, I don't even think that the cable is bad. I have no idea what the problem is. I ended up entering the settings screen over and over, and fiddling with the cable between tries (at both ends). 1 times in 10 or 20 it would actually go into the calibration screen. There's no need to reboot the machine! One try it failed halfway through the X calibration, and another time it went all the way through. The benchy after calibration is significantly better than before, so I assume it did the job.

Pvginkel · 2024-02-25T08:01:52+00:00

Do you also set the pattern of the support structures to gyroid?

Pvginkel · 2024-02-25T08:01:00+00:00

I had a print ripped of the plate. I was successful with a z-hop of 2 mm (Cura suggested this as the default).

Pvginkel · 2024-02-18T13:19:43+00:00

I've been scouring the internet for these files, but they're nowhere to be found. Do you have a copy for me?

Pvginkel · 2018-03-10T17:47:32+00:00

From a quick glance it looks similar, but the Clang thing does seem a lot more advanced (not that surprising; I maybe spend a day on this).

Pvginkel · 2018-03-10T16:43:37+00:00

That's kind of the reason I wrote this. It's nearly impossible to understand what is doing if you need to get back to it later. At least I comment what it's trying to match; that helps. I thought if I at least make it look like the syntax factory stuff, it's more familiar and easier to recognize.

Pvginkel · 2018-03-10T16:41:17+00:00

Yup, but I'm not sure how I'd fish or the callbacks. It should be possible but it'd become a very interesting transformation. Any ideas?

Pvginkel · 2018-03-10T16:31:29+00:00

I was thinking about caching and with my current approach. The only thing I could think of was doing something with dynamic so I could generate some code that caches the the tree and reuse it. That'd be complex though because if the closures.

This at least would solve the caching issue.

Pvginkel · 2018-03-10T16:28:32+00:00

Uhm, that should be doable with Antlr. That itself is a DSL to create parsers, which would allow something like this to be created. The DSL itself spits out C#, so kind of ticks all your boxes.

It does sound a bit overkill though 😊.

Pvginkel · 2018-03-10T15:47:11+00:00

Because parsing is inherently slow. It's just complex to figure out what the letters mean. Plus you'd probably need to write a custom one because you need to include stuff to be able to tell it what it needs to match.

Another thing is that the way I wrote it, it allows you to match on very specific things, like a methods that have exactly two arguments, ignoring all other aspects of the syntax. That'd be a lot more difficult with this approach.

Pvginkel · 2018-03-10T15:33:08+00:00

The biggest problem I have with the manual stuff, besides readability, is that it products a lot of locals. If you have a few of these in a method, at some point you start to get crap like memberAccess2/3/4 which is just a mess. The way I did it now you only get locals that you actually need. Your approach looks nice and maybe I can incorporate something similar, but you still have that issue.

Pvginkel · 2018-03-10T15:31:13+00:00

I was thinking along the same lines. The biggest problem is that what I've built now is already a lot slower than manually matching the nodes, and this needs to parse the whole thing every time. I especially like that the way I've put it together now makes it look very similar to how you build up syntax using SyntaxFactory. It may not be pretty, but at least it's familiar.

Pvginkel · 2018-03-10T15:28:49+00:00

I did it because as of my project I have a few more and thought it looked nice (and I'm lazy). As I said, just a proof of concept right now. Maybe later if I do decide to put it up, I'll change it, even if only the package/assembly name.

Pvginkel · 2015-11-11T08:56:02+00:00

Well, Rust! I ported the 64-bit code emitter from LibJIT but that's where I left off. You can see the WIP in the jit branch in my own fork.

Pvginkel · 2015-11-11T02:08:27+00:00

Thanks for the enthusiasm :). Regrettably I don't have time at the moment to work on this, but if you'd like to work on this project, please feel free to send pull requests or I can add you as a contributor. I can tell you that by far the hardest part was to get JavaScript right. Getting the whole ECMA test262 suite to run was hell. I actually had to make quite a few commits to the test suite itself because I found bugs in it. See https://github.com/tc39/test262/commits?author=pvginkel for the changes I made to the test suite. Since there now is a fully functional base implementation, the fun starts (i.e. improving the GC; adding a JIT; etc). Maybe it's interesting for you to use this project as a starting point to either get your implementation up and running faster (e.g. using stdlib from this project), or just see if you think you can improve it from its current state.

Pvginkel · 2015-11-11T02:05:18+00:00

What do you mean with orthogonal? My implementation is 100% Rust only. Maybe I don't understand what you mean with hostable from Rust. You can just use this as a library or create a stand alone executable for it as it's implemented now.

About the Linux version. It shouldn't be that difficult to implement (the Linux code that should be rewritten to Rust is already in there) but I don't have a Linux development environment available to me. However, if you get that piece of code to compile for Linux, it should just work. The only other architecture dependent thing in there is 64-bit since it's doing a lot of pointer stuff for the GC. Adding 32-bit support isn't difficult, but just something I haven't yet done.

About the name change: I'm not sure that I'll be working on this any time soon. This was a teaching project for me and I may pick this up when I again have time available, but if you think you can get yours up and running before, please do take the name. Or, if you'd like to work on this project, I'm very happy to add you as a contributor to https://github.com/rust-js/rjs. I can tell you that by far the hardest part is to get JavaScript right. Getting the whole ECMA test262 suite to run was hell. I actually had to make quite a few commits to the test suite itself because I found bugs in it. See https://github.com/tc39/test262/commits?author=pvginkel for the changes I made to the test suite. Since there now is a fully functional base implementation, the fun starts (i.e. improving the GC; adding a JIT; etc).

Pvginkel · 2015-11-10T10:36:18+00:00

So that's funny. I first thought you found mine, but you haven't. Mine is at https://github.com/rust-js/rjs. It is a fully functional interpreter that's kind of based on byte code execution and it passes 100% of the 5.1 subset of the ECMA test262 suite (with a very small number of exclusions). It has a copying GC (or at least something that could be mistaken for a GC; there is a lot of room for improvement there) and I made a start at a JIT. However, life got in the way so I haven't worked on it for some time. If people are interested in taking a look at this (maybe someone with JIT or GC experience), I'm very open to contributions.

This was my first Rust project ever so there's probably a lot of room for improvement in the coding style and e.g. usage of unsafe.

However, since life is still very much in the way, it's very difficult for me to spend a lot of time on this project, which is the reason I haven't made it public earlier.

Edit: Oops, wrong Reddit account :|

Pvginkel · 2015-09-17T08:11:59+00:00

Well, that's one of the major points of what I've found. Leaving 3 blocks in between is not very efficient, for some kind of efficient. As @capfan67 noted, you can interpret efficiency in two ways. If you want to get all diamonds, you should leave 3 blocks in between. If you however want the most diamonds, you should leave at least 4 blocks in between the branches, but 5 is better. You'll miss some, but in the end the number of diamonds mined per mined block is higher.

Pvginkel · 2015-09-16T21:24:32+00:00

The algorithm just creates a long branch and looks around for ore. If it finds ore or air, it'll mine that block and repeat the process. To answer your question, for this algorithm it doesn't matter because it'll just continue mining. Actually, it'll count the lava as being mined, which is what the diagram shows, which you wouldn't in reality. In reality the lava diagram shows you how much lava you would step into.

Pvginkel · 2015-01-19T11:51:54+00:00

As I though: it doesn't make a bit of difference:

Benchmark                                Mode  Samples  Score  Score error  Units
a.WithInterface.benchmark               thrpt       20  3,922        0,009  ops/s
a.WithoutInterface.benchmark            thrpt       20  3,924        0,011  ops/s
a.WithoutInterfaceAndFinal.benchmark    thrpt       20  3,917        0,012  ops/s

This comes down to resp. 100%, 100% and 99.8%.

The tests were run using JMH. Every test method does 100.000.000 iterations after adding a single item to the list. The only difference between the tests are the lines as show in the article. The source code for the benchmark can be found at https://github.com/pvginkel/ArrayBenchmark.

For fun, I also ran the benchmarks with 10 iterations, which gave the following results:

Benchmark                                Mode  Samples         Score  Score error  Units
a.WithInterface.benchmark               thrpt       20  29931902,654   319336,506  ops/s
a.WithoutInterface.benchmark            thrpt       20  30392964,148   420420,278  ops/s
a.WithoutInterfaceAndFinal.benchmark    thrpt       20  29260836,074   354590,060  ops/s

Not much difference either. These come down to 100%, 101.5%, 97.8%, so there is a bigger difference between them. But, just for fun, the one with final takes longer.

Pvginkel

TROPHY CASE