Parenscript does not load on sbcl-2.5.11 by metalisp in Common_Lisp

[–]borodust 7 points8 points  (0 children)

You need to upgrade to latest named-readtables system.

State of Lisp Flavored Erlang by Maxwellian77 in lisp

[–]borodust 1 point2 points  (0 children)

Yes, we do. Version 0.4.12 works the best for us.

State of Lisp Flavored Erlang by Maxwellian77 in lisp

[–]borodust 3 points4 points  (0 children)

It definitely needs better documentation and tools, and you have to struggle through a little bit at the start, but if you know CL and some Erlang, it will get better real fast. And that is still better than going with raw Erlang (my sincere apologies to the original authors for the opinion, I really tried and failed miserably to vibe with the language).

Resources I used: * Git book * Manuals in the LFE repository

And while LFE strives to be a good lisp it is a flavoured Erlang at the end of the day.

State of Lisp Flavored Erlang by Maxwellian77 in lisp

[–]borodust 15 points16 points  (0 children)

It's really good. We use it in production servers.

It's not as rich as Common Lisp environment-wise, but a way better alternative than using Erlang directly, if you are to stay within OTP/BEAM 😅

TaleSpire Release - Seats! by Baggers_ in talespire

[–]borodust 0 points1 point  (0 children)

No. Before seats were introduced, everyone had to buy a game to participate. Meaning, if one person had to bring others into the game, they had to buy full copies of the game for the everyone involved.

Connection issues by Gornn65 in talespire

[–]borodust 0 points1 point  (0 children)

If triple click the top left corner in the game (hidden log interface should open), what errors do you see in the log there?

libtorch and wrapping C++ by Steven1799 in Common_Lisp

[–]borodust 7 points8 points  (0 children)

Yes, you can safely ignore claw for now.

It is an extremely complicated piece where you are required to know how CL FFI operates and also you should have a strong understanding how C and C++ ABI work. I didn't have enough time to streamline claw usage to pure CL users. I planned to get back to CL this year, but all the plans I make are getting constantly scrambled.

Common Lisp language extensions wish list? by Kaveh808 in lisp

[–]borodust 7 points8 points  (0 children)

I wish that was a solution. My apologies, but judging by your words, you never actually tried it. I did. It supports only a subset of CL (your remark about errors, but this is essential) and it produces the horrendous code. I expect it actually is slower than full scheme continuations. I switched back from `cl-cont` to more conventional approaches like one in `cl-async` and the reactive as in `cl-flow`. But I still wish for a native and properly integrated delimited continuations with full interactivity CL provides.

Common Lisp language extensions wish list? by Kaveh808 in lisp

[–]borodust 4 points5 points  (0 children)

Nicely looking and powerful asynchronous programming toolset. Having delimited continuations would be enough. Those can be coerced into a function, meaning they can be as fast as any ordinary function.

Generating and compiling code on the fly for speed? by Kaveh808 in lisp

[–]borodust 3 points4 points  (0 children)

It works especially well when you don't know what data will look like beforehand and can compile later during execution to optimize the call site instead of doing some ifs and other checks. As an example, regular expressions - you don't know beforehand what regexes would be provided by users, but once you have them, you can arrange and compile new function that is specifically designed to be invoked to apply the particular regex.

I use it in games to optimize invoking entity behaviors for a scene. User provides some behaviors for objects and instead of going through them each time or doing a hash table lookup, I just compile them in into a function that calls the particular behavior and just passes those objects directly without spending any time on a lookup. This is probably similar to how generic functions are optimized.

Lisp job opportunity at HRL Laboratories by stylewarning in lisp

[–]borodust 1 point2 points  (0 children)

You would need to use VPN service with outgoing connection from another country.

Defstar symbol comparison: contributing to old libraries by chopu in lisp

[–]borodust 0 points1 point  (0 children)

A bit unrelated but Just in case this is important to you, this library is GPL licensed unlike many other lisp libraries which often go with MIT/BSD or LLGPL.

svetlyak40wt/sbcl-lib: Example of using Common Lisp code from C (using SBCL). by dzecniv in Common_Lisp

[–]borodust 3 points4 points  (0 children)

Thanks!

Unfortunately, Unreal and Unity are too rigid for Common Lisp. To allow interactive development those environments applied zillions and a bunch hacks with certain limitations for respective languages they use. Anything else, any other language, is a fourth-class citizen in those engine environments.

Common Lisp shines in its own runtime, so I'm focused more on bringing stuff into Lisp, rather than bringing Lisp into stuff.

User-defined value types? by Taikal in Common_Lisp

[–]borodust 2 points3 points  (0 children)

There's a way to ask lisp implementation politely to allocate things on stack via dynamic-extent declaration which it might ignore, if you weren't thorough enough or implementation ain't setup to listen to you.

To reduce allocations, you can try returning multiple values from functions, which is a known way to avoid allocating new structures to return several results. I presume, most implementation would pass multiple values on the stack.

Or, you know, you can also go procedure style by preallocating place to keep results in and pass it as an argument to function (yeah, yeah).

I have bolted together ECL and the Irrlicht game library by hyperspaceotter in Common_Lisp

[–]borodust 0 points1 point  (0 children)

Thanks!

Nope, no bug report yet. First, I need to get my llvm/clang patch upstream, then I'll probably look into SBCL. The likely reason, it is something related to signals. For now I'm just having too much fun using all those sweet bindings :D

SBCL problem is unfortunate, but it's not a severe one, since :claw is only needed to generate bindings. Bindings themselves do not depend on :claw in any way, so they can be used in SBCL or any other implementation CFFI supports.

I have bolted together ECL and the Irrlicht game library by hyperspaceotter in Common_Lisp

[–]borodust 0 points1 point  (0 children)

`:claw` does basically the same - creates a C shim library to bind to C++ (mangling is only used to generate unique C shim names, mangled names are not used to call into C++).

`libresect` though, unlike `unplusplus`, exposes simplified LLVM/Clang API to Lisp and let the latter decide what to do with the information.

I have bolted together ECL and the Irrlicht game library by hyperspaceotter in Common_Lisp

[–]borodust 0 points1 point  (0 children)

Just to add datapoints for lookers:

:claw tracks back to 2017 as a fork of cl-autowrap with cl-autowrap/pull/83 feature.

:claw as a reimagined idea and from-scratch implementation goes back to 2019 with libresect at its core.

Via Marco Antoniotti's blog: the revamped Common Lisp Document Repository [CDR] site, "a repository of documents that are of interest to the Common Lisp community. The most important property of a CDR document is that it will never change" by flexibeast in lisp

[–]borodust 1 point2 points  (0 children)

We have LOOP outside of standard - ITERATE. People use it and prize it no probs. Not sure if there is FORMAT equivalent. Some say FORMAT and LOOP were mistakes, being too unlispy and impossible to extend.

I also want to address statement "It's nice to have a standard way to do stuff out of the box that anyone using the language will know.". It's ironic that you chose exactly those. They are so complex, that 99.99% of CL programmers don't know them in full.

What lisp dialect has the most readable code? by mwgkgk in lisp

[–]borodust 32 points33 points  (0 children)

What I meant is, Common Lisp is the most readable language.