abricq

I notice that user JiaT75 is still the second biggest contributor of the project. Interesting that his account is still alive.

This rule is required because "as in chess", a pawn may promote to bishop.

If you only remove the bishops from the starting position, then the rules of chess still allow bishops to come in later in the game (through a promotion).

I am assuming they did not have enough memory to hold the rules of bishops, and therefore decided to completely remove them from the set of possible pieces. They allow rooks and knights promotion because these pieces are in the set of initial pieces: their rules are already implemented.

Looks quite interesting ! Since this was done as a university project, did you have to write a report ? If you did and that it can be shared, I would love to go through it

To be fair, the second sentence is

> Lasso is [...] licensed under the GNU General Public License

I don't think that engineers must design product only because of "why not doing it if we can do it". There is a ethical value to what we design and produce. Some technologies are better than others.

Probably, the predominance of cars in our modern societies (and cars always getting bigger) is one of the factor that yielded to observations made in this article.

But in some places (for instance where I live, Lausanne Switzerland) it's becoming easier to escape this car culture. I don't have kids, but some colleagues do. One of them does not own a car and her 2 children (6 and 9 years old) do everything by bike : going to school, to the activities (they climb!), etc. They surely look much more agile and risky than other colleague's children. It's quite crazy to see these two kids on their bikes, and how much liberating it is for them to move by theirselves. Unlike most kids who just commute in their parents's car.

Of course, I am aware this works only because there's a really good bike infrastructure. And people drive pretty well too, I guess.

I commit the symbolic code on its own file, in the same commit which adds the c code.

We target very low-level & specific hardware. I don't think it would be easy to deploy Jax on it. But it's an interesting idea, maybe for robots running linux !

Well, the symbolic computation is only used to generate C code. The generated code then evaluates jacobians numerically. And we use several methods for numerical stability on top of that.

Working in the field of robotics, I often have to write big vectors (usually computed as the result of 3D transformations) and then compute their Jacobian (their derivative with respect to several state-variables), which quickly becomes very nasty equations. I use sympy to (i) compute these big vectors, expressed in a very declarative way, (ii) compute the jacobian and (iii) export the results in C-code, immediately importable in my code case.

To illustrate what I mean by "expressing systems of equations in a declarative way", here is a toy-example of how to estimate the position of the a sensor with respect to a robot's center if you have access to a dataset containing robot positions and the sensor positions. The 'naive' approach (it very often works) is to solve an over-constrained system with a gradient-descent. To perform a gradient descent, you need a residual function and its jacobian. Here's how you would do to compute it with Sympy. (Note: you'd just have to define the `transform` and `invert` functions...)

    # Pose of a sensor in robot frame (to be estimated)
    xa, ya = symbols("xa, ya")
    a = Matrix([xa, ya, ta])

    # Position of the robot at time t
    rx, ry, rt = symbols("rx, ry, rt")
    rk = Matrix([rx, ry, rt])
    
    # Measure of the sensor at time t
    gx, gy = symbols("gx, gy")
    gk = Matrix([gx, gy, 0])
    
    # Estimated x (from the measures)
    estimated_a = transform(invert(rk), gk)
     
    # compute the norm of the gk, squared
    n2_mat = norm2(estimated_a - a)
    n2 = sympy.collect(sympy.expand(n2_mat[0, 0]), a).simplify()
    
    # Compute the jacobian
    J = n2_mat.jacobian([xa, ya, ta])
    
    # Print what is necessary for Guass-Markov regression
    print("\n\nres =", n2)
    print("\nJacobian = ", J)

I want to make this happen ! Do you know of any good robotics framework in Rust, as of today ? I heard that ROS2 was slowly including Rust [1], not sure at how did it go. Ros would be a good entry door to sensor fusion, mapping and localization. Because all of the hardware integration / abstraction is already done (in C++). I'm curious to know if company are using this.

[1] https://github.com/ros2-rust/ros2_rust

Maybe not converting legacy code, but starting new projects in Rust !

At my robotics company (where I lost so many hours compiling overly-templated code in C++), I was able to convince my boss to start a new small product in Rust (was an internal simulation tool) and it convinced him to let me work on another new product a few month later, also in Rust, on a much bigger scale. He had only ever worked in C++ before, and I guess he doesn't mind to loose hours compiling and fixing memory leaks. But regardless, it worked and now I can work (a bit) in Rust.

Looks real fun. Was it easy to deploy it on your website ? did you compile in web-assembly ? Or are you hosting all the logic onto a local server ?

Bless your mess !

That's true, I guess we see a lot of "success project" and feel ashamed to share our projects with half-started README. But what a great coffee-with-colleague-topic it makes !

Writing small, unfinished projects is great ! At least I think so. It's what keeps me passionate. It's a way to learn new things (language, framework, etc...).

I don't like much the phrasing "I give up". How about "I had fun, learned while enjoying it, and now move on to my next unfinished project". Great article though !

In-house compiler, specifically made for the architecture that we sell, we have to maintain it but we rarely touch it. I am quite sure that it was related to System3, I know that we used to use System3 in the past. But this part I am not sure, as I am quite young and I personally never worked with it. Unfortunately it's not open-source, but it's just a standard compiler pretty much without optimization. In our case, it's the responsibility of the developer to write optimal code, since our compiler does help. I'd be curious to chat about your version of embedded Oberon, I will write to you !

Thank you, I got it: "Protocol extension, a technique for structuring large extensible software systems" [0] ! Hoping to find time to read it soon, and also to look at your ruby compiler !

[0]: https://www.research-collection.ethz.ch/bitstream/handle/20....

I'm curious if you have some references about this, if you have read good blog posts or something ! I can think of Rust that does not have exception, but it's not because they didn't address the problem of error handling: exception are replaced by `Result`, if I'm not wrong. In Oberon there's simply no error handling mechanism.

> Franz was one of the people who around that time wrote a report on a proposal that'd enable runtime-loadable interface-based extension

You seem to know a lot about this time. Would you have a reference on this report ? I am quite curious now !

Every now and then I look at this site, I hope the project keeps growing !

About the what, I can't tell you too much unfortunately. We do realtime OS for autonomous robots in Oberon. About the why, it's a question of heritage from the past. The code works, so why taking the risk to migrate it. It's really a big code base, so migrating it would be (will be...) very risky for all of our running platforms.

Interesting to see that Oberon-2 tried to go where Java succeeded. I guess java worked better because of language limitation. From my experiences in Oberon-2 (I work with it), I find the following limitations enough to explain it.

- No generic types. That's really limiting. You want to implement Linear Algebra for vectors ? You need a class for each possible types.

- No proper error handling : no such thing as `TRY` or `CATCH`. Instead, you need to pass a `BOOLEAN` mutable flag in functions that may crash. That's just sad.

- No distinction between a class, an abstract class and interfaces / pure abstract classes. If you want to write an abstract class, you just `HALT` in the base methods (like you would do in Python I guess). But there is no language semantic to define that this class is abstract. So the compiler can't help you out much with them.

- No enumerations. They are just very powerful.

(- Faulty garbage collector, even though that is not a a feature of the language but rather of the implementation that I am using.)

I am quite sure that Oberon was written with a real focus on designing a language for which it is easy to write a compiler / garbage collector. It really made sense back then. And they succeeded in doing so. However, for broad distribution of executable, it probably wasn't the best guess. These glimpses of the past are so interesting though, discovery of the most optimal tech stack was a long and dense path of exploration !

Of course code coverage should not be seen as the only way to measure testing. But should it be systematically disregarded ? I rather see it as one of the tool for QAs to know where they stand at : 5% code coverage vs 85% is still an interesting information to have.

Totally agree that code coverage is not a sufficient metric for quality, but it's still an interesting one.

At my company we have this language that is not mainstream (Oberon) and therefore there was no code-coverage reporting at all. I found this paper and realized it was super easy to write a minimal code-coverage analysis from our AST parser and code formatter (internal tools). Somehow it had never occured to me that it was this simple.

The transition from "no code coverage at all" to "seing which module is covered and which is not" was really insightful !

This looks really cool, for sure I will to try this out ! I will look into it for Italian.

I'm not sure how much work is it for you guys to add a language, maybe it's easier for you to add languages than for other mainstream platforms thanks to the use of AI ? If it the case, it would be really nice to have one serbo-croatian language, such as croatian or bosnian.

I struggled to find ressources for these languages. Since a few months I have been trying to learn Bosnian (going on a long trek in the balkanies this summer) and I was just not able to find any "modern" service (Duolingo, Babel, etc ...) which supports these languages. I guess it makes sense since almost no-one wakes up and decide to learn Montenegrin, but maybe you can find a niche market.

Anyway, cool product ! I hope you guys make it.

When working in a team, having a lightweight shared git remote for sources is super handy. For instance Gerrit, or what uses Google (Critique I think it’s called). For sure these services have a little bit of JS for things such as code reviews, but they’re useable without any.

For sure as of today GitHub is a web app, but it's questionable whether it should forces you to use it as one. In essence, GitHub is just a remote server for a .git folder. This does not need any JS.

I see that GitHub now tries to become at the same time a social media for hacker-friendly people and some sort of super-CI server with automation. For sure these are good features. However I also see why people are sad that the old (and defining) functionalities stopped working without JS.(look at commit, browse the sources, read and submit issues / PR and code review). It saddens me a bit to often see working websites getting more and more complex, adding more and more features, probably to remain "fancy" and competitive.

If someone is interested, here is the Reference and Implementation Guide of the latest NTP version (2006, was revised in 2010), written by Dave Mills: https://www.eecis.udel.edu/~mills/database/reports/ntp4/ntp4...

Quite well written, in my opinion.

I don’t think there is any advantage to start a new code base in Oberon. The language itself is just like any OOP language, with very pronounced limitations. Typically, you’ll often have to fix problems with the compiler, or with the OS.

I guess that sometimes the risk to make a language migration (and to introduce some bugs) is higher than the performance benefits.