[ann] mltree cmd

Hello Dear List.

Now ‘mltree’ also has an option to display md5-digests, in addition than the 3 time-stamps, the unix read-write-exe for the three categories, and file-sizes.

And there is now also an .html output in addition than the console output from its first version.

It is not in opam, because everyone (including me), will probably prefer the original tree command.

I just wrote this (not-really equivalent), because I so like the ocaml programming language.

The author of mldonckey said we could also re-write all the other commands.

This is not something we need, this is just something pleasant to do.

Thanks again.

1 Like

Do you have a link where we can take a look at it?

Yes, in fact there are four actually.

This is why I thought it would be better not to put it in the message.

Because people who are really interested will easily find it if they really want.

I tried searching for it, unfortunately ‘mltree ocaml’ gives really generic results:

So if you want people to look at it, you will probably have to share a link :wink:

Hello Yawar Amin,

Twenty years ago, I read messages from ocaml students on the forums, about the fact that they don’t have any bindings to create their games for their studies, and no tutorials to learn gl in this language.

ht tp://decapode314.free.fr/ocaml/#Interfaces

So I made some for sfml, clanlib, sdl2, sdl3.

Also trying to help for chipmunk, ode, irlicht, ecs, im6, im7, gm, gegl, svg, pov.

Twenty years later, there was nothing made, with all these things.

Daniel Bunzli was talking about “engaging-contents”.

This is obviously a complete failure for me, because I obviously failed to create “engaging-contents” to engage some people to make things with it.

This is why I’m not sure giving a link or not will make any difference.

This is just me who is not able to create an environment that will make some-one want to create something with all these elements.

I’m trying to figure out in which way I should change the contents to make these engaging, but I’m not sure this is beyond my skills.

Giving a link or not will not make much difference.

People prefer to make games in Haskell.

GitHub repo GitHub - fccm/mltree: utility similar to the unix command 'tree'

Now there is fccm2 because I lost the password.

And I’m very worry that the fccm got deleted, because I know that very often an unused account are deleted after a period of being unused.


Passwords should have 12, 16 chars, after a number, special chars, and after it’s not enough, it should not be written on a piece of paper, and it should not be a word from the disctionary, and after you need to buy a smartphone, where you recieve thousands of adverts.


The last one is on fccm2, the previous one doesn’t have md5-digest, and .html output.


Anyway no-one will use it, so why giving a link ?


Does out-reachy helps the students who failed to get their diploma ?


The survey says there are a lot of people using ocaml at home, but it doesn’t say if their profession is programmers or not.

For the same reason you chose to share its existence here, whichever that is! You clearly want to share your projects, otherwise you wouldn’t have opened these threads. So why won’t you give your own projects an actual chance? Be proud of them even if they don’t find mass appeal, the power-law of popularity is harsher than ever anyway.

Your work alone couldn’t have achieved that. For most of those twenty years, OCaml as a whole failed to gain mindshare and failed to support features needed for gamedev, like Windows, multicore or unboxed types. Meanwhile, game development completely shifted from libraries to commercial game engines (and the seldom XNA-inspired library), most of them using C# or C++ for client code. Very few people handroll their game engine now and much of the tech you wrote bindings for isn’t revelant for it anymore, the main exception being SDL.

So no amount of bindings for 2000s tech would have been enough to form a gamedev community in OCaml. Game devs and OCaml were headed in very different directions already. Only maybe now with multicore, some OxCaml features and the new SDL3 GPU API (which I think will bring back a lot of custom game engines for indie games) I see a really small chance for OCaml to catch up.

2 Likes

It really depends of the type of game. In the visuals novels (like Slay the Princess, Videoverse or V1-11-Hal-A), there is no requirement for performances or advanced effects. In this kind game, you have a story based on text, and the game just ask some basic choices to the user and update the story consequently (like a state machine).

Most of the engines are free: for example Renpy or Twine, and each of them created their own language which can be used very easily, even for non-programers. For example (using the qsp language):

act "Swim in the water":
    "You swim in the water and enjoy the pool"
    hunger += 100
    gs 'exercise', 15, 'stamina'
end

or (using the renpy documentation)

define s = Character('Sylvie', color="#c8ffc8")
define m = Character('Me', color="#c8c8ff")

label start:

    s "Hi there! How was class?"

    m "Good..."

    "I can't bring myself to admit that it all went in one ear and out the other."

    s "Are you going home now? Wanna walk back with me?"

    m "Sure!"

I think that OCaml can get a very good place here: we already have a lot tools, but they just are not connected together yet:

  • Lexers and parsers
  • Very strong code analysis
  • Compiler for foreign languages (I’m thinking about malfunction here)
  • Plugin system
  • Both binary and javascript target

In my dream, the idea is not to write a game in OCaml itself, but to use OCaml for building a game engine that anybody could use with a minimum of knowledge. Idealy, you would be able to use OCaml code at any time if you need advanced function.

1 Like

There is also maybe NO motivations inside the ocaml-community to create an equivalent than pygame, or ruby’s gosu.

When I say No Motivations, I mean no-motivations others than-me . ?


Again they said twenty years ago that they don’t have any bindings to create their games, but now that there are some, there are still No-Games done.

is anyone working on ocaml bindings for these? I would be very interested

ht tp://decapode314.free.fr/ocaml2/sdl3/

I’m still a beginner, I still have to understand which between Scancode and Keycode is the actual keys on the key-borad, and wich one is the language-mapping one. I can ask a chat-bot tens times, it will always reply as if it’s not tired to reply the same thing.

(to-sanette) it will be nice if you also make one with ctypes.

The greate adventage of ctypes seams that it will not fail on a small api break, if a broken function is not used, and if only the remaining ones are in use, the programs will still work.

yes if I ever try that would be with ctypes.

maybe @dbuenzli has the project to extend tsdl to SDL3?

For now I’m simply maintaining tsdl as it is, trying to do my best at integrating stuff that other people suggest. I personally no longer use it as I tend to turn myself to the browser when I need a multimedia API. Also I heard there are perhaps (?) nicer APIs out there for what SDL provides.

So the answer to the question is that it depends on what it takes. I did not follow the SDL2 to SDL3 process and idea (what and how much changes, what it adds, what the compability story is, etc.) but I’m inclined to say that unless someone does it for tsdl or someone wants to fund me specifically to do this, it’s unlikely.

3 Likes

The big change imo is the gpu API. It offers a graphics API with an abstraction that sits somewhere between gl and vulkan. I’m also interested in such a binding.

The use case covered by raylib is a bit different (thanks for linking). It’s explicitly aimed at beginners and teaching, but still offers access to raw GL as an escape hatch for intermediate users. It’s okay for smallish games and getting started but not something which is expected to scale to high-end use cases (although the last version also supports compute shaders). Whereas sdl3 with its gpu abstraction should be able to support these use cases as well.

Both sdl and raylib support compiling to wasm btw, and OCaml now does too. I would love for someone to make them talk to each other (through ctypes?).

2 Likes

I think Raylib is nice! I would personally prefer to use it over SDL if my only concern was how nice it is to work with.

Raylib depends on GLFW though. GLFW is also nicer to use than SDL in my opinion, but GLFW’s Wayland support is a bit experimental at this stage I think, so I would probably want to go with SDL which is backed by a major corporation and probably has anything else beat as far as “something that works everywhere” goes.

The only issue I’ve experienced with GLFW on Wayland has been clipboard management, which is a rare thing for a game to want to do, but it’s another relevant concern if picking between these libraries.

It has been nice to develop my code with purity/a functional core in mind so that switching between these libraries is less of a pain, but I’ve still been a bit too lazy to do that since I would rather work on developing new things for the functional core. :sweat_smile:

Maybe you missed them but I think there are a few recent projects out there see for example

1 Like

Gamelle supports compiling to js, but it does not use the fact that the sdl can compile to WASM. Instead it has two implementation of the same interface, one through JS canvas and the other through SDL bindings.

The JS canvas interface is a lot nicer by the way, especially when working in a GC language where “allocating a texture” is not necessarily something you wanna think about.

Indeed I don’t know gamelle, but it’s described as a game-engine.

PyGame is not a game-engine, it’s a base, to build things with it.


The only of the packages I’ve done that got users is glmlite, maybe because I used a template from professional origine. There was zelus, and wander, but I can’t find the sources anymore from both. It was probably from another goal than to really use it.

Reaching PyGame’s quality is probably very difficult.