kyren / piccolo Goto Github PK

How would I do this? I've skimmed through the compiler code but as its 23:30 of the time of writing this i can't fully look into the entire source to see how Lua gets compiled to bytecode gets compiled to instructions or if it's Lua straight to instructions and skips bytecode entirely.

I've looked through the compiler example and it seems to be exactly what I'm looking for but i don't know if the prototype is a tree-like value that i can walk through with a simple for loop and a match statement.

I just checked out this project and it seems like there's a memory corruption happening when running the tests. I'm not sure you are aware of that, so I'm just letting you know in case.

Critical error detected c0000374
Exception thrown at 0x00007FFC01204D1B (ntdll.dll) in basic-66257f80e6d12447.exe: 0xC0000374: Ein Heap wurde beschädigt (parameters: 0x00007FFC012697B0).

Not proposing this as a feature but just wondering if it would be possible in theory to save and reload the entire Lua state? Given the "stackless vm" design and the "reified stack", it seems like it may be more possible than in other designs so I thought I would ask. I expect that if nothing else, the Rust callbacks that are stored in the state would be unserializable, but curious what other deal breakers there might be?

Been going through my open source projects which I've been neglecting and figured I should write something here about where I am with this project.

Unfortunately I'm no longer working on a larger project where I think this might be useful
(for my current needs wasm is a better fit), so I'm not going to update this
project at least in the near term. I still think the core part of this project (safe interaction with a garbage collector via a futures-ish API) was a neat idea, and I'd still like to explore
this in the future when the hopefully the compiler is a bit more ready.

Before I pick this up again though I think that there needs to be additional
support in the Rust compiler for doing this, because while it is possible to use a GC safely via combinators, it is not at all pleasant. What I'd like is for it
to be possible to have a safe GC'd API using async / await or generators, but
AFAICT right now it is not possible. I tried for a while recently to see if I could come up with even a very limited version of the "sequence" API that worked with async / await functions and I couldn't find anything that worked.

You can't auto-generate Collect for closures or generators right now which is certainly a
limitiation, but it isn't actually the biggest problem currently. Right now
there's no way I can find to pass a Context<'gc> with a unique, branded 'gc
lifetime through an async function while having that async function not also be
of the 'gc lifetime. We need the async function to strictly outlive 'gc so
that it can't hold Gc pointers across await points, or we need some other
solution. (Incidentally I can't make this work at all right now, but even if
I could I know that you can't make the lifetimes work out so that the async
function lives for longer than 'gc).

Once I find any way of proceeding that enables generators-like functions instead of combinators, I think I'll pick this back up, but until then I'm not going to update this.

I'll keep thinking about the problem though! If anybody else has any ideas about how to make this work, let me know!

Hi! Thanks for the project!

Recently I did a lot of PGO benchmarks on different kinds of software - the results are here. I think the same optimization option could be useful to Piccolo too.

I understand that the project is in the early stages of development so it's probably not the right time for asking about such things. But maybe one day this day will come and we will be able to perform PGO testing (and documenting its effects on Piccolo). For the users will be helpful to see information about PGO effects (and other performance tuning techniques if any) to improve Piccolo performance.

If you are going to play with PGO, I recommend starting with cargo-pgo.

I've started to have a play with luster to see how it might fit into another project.
I was wondering about adding some of the table functions, but notice that the next function isn't implemented yet.

Before I start poking around in Table, do you have thoughts on an approach? Replacing the FxHashMap with something like IndexMap might work (that IndexMap doesn't quite do everything needed as far as I can tell).

Thanks,

Chris

Hello,

I have just been pointed to this repository, as I'm currently investigating scripting languages accessible from rust that would support builtins that return -> impl Future<Output = TheActualResult> (and thus have all lua functions when accessed from rust that would implicitly return -> impl Future<Output = TheActualResult>) in a way that would be transparent to the scripted language, for the configuration file of a server I'm writing.

Until now, the only language I had found that matched this property was gluon, but going with a brand new scripting language makes me uneasy, as users would have to learn it in addition to understanding how my server works.

So I wonder, is async builtins / callbacks being transparently “async'd” through the lua call stack until the initial rust caller something you are considering for luster?

Cheers, and good luck with this rewrite!
Leo

Problem

Self descriptive

Versions

Rust: 1.72
Piccolo: Both 0.1.0 and 0.1.1

Reasons

Iterpreter example

Changes in API. No reset method for Thread and more

Compiled example

The trait bounds are not satisfied

Seeing how Lua 5.1 doesn't talk about it but LuaJIT does, I'm guessing it's LuaJIT?

Hi! I'm wondering what the future of this project will be now that Chucklefish has decided to not use Rust for their next title.

Hello, I would like to know what you had envisioned for the rust API <-> lua binding. What's the progress on that front and how one could contribute? Thanks.

https://github.com/kyren/luster/blob/3e3a6ea12f6f523c105abd7fbe9d0ad226be784c/gc-arena/src/util.rs#L47

This operation looks like it's supposed to be a bitmask, but instead of doing an AND, it does and OR. As such, the inequality will always be true.

I just published a crate named luster, not realizing that there was a Rust program of that name.
I dont mind trying to change my crate if you might still want the name 'luster'.

Just let me know!

[zaoqi@zaoqi-pc lua]$ lua -i lang.lua 
Lua 5.3.5  Copyright (C) 1994-2018 Lua.org, PUC-Rio
> 
[zaoqi@zaoqi-pc lua]$ ............../luster/target/debug/luster -r lang.lua
Error: ThreadError(BadCall(TypeError { expected: "function", found: "nil" }))

https://gitlab.com/the-language/the-language/blob/d13341505075cb8cc4fa9b23212fd9c9932bc556/core/pure/lua/lang.lua

I assume the reason these constants exists is pattern-matching: https://github.com/kyren/luster/blob/413b5c675d5747b26c19bd34eb4ed56e9fa956ff/src/lexer.rs#L852-L906

But instead of e.g match c { SPACE => ... }, one can write match c { b' ' => ... }.

gc_arena and friends seem very useful! It could be a separate crate.

I've noticed that assignments with functions with multiple return values doesn't work. For example:

function mulret()
    return 1,2,3
end

a,b,c = mulret()
print(a,b,c)

In lua gives:

1       2       3

In Luster:

1       nil     nil

I think the problem is in the handling of assigment statements in the compiler, which seems not to have allowed for multiple returns yet (the function is called with 1 expected return value).

Hi, I recently created a PR on rlua that adds ability to nest MultiValues which makes it very convenient to allow new kinds of parameter unpacking in registered functions. It hasn't been accepted yet, but I propose this addition to piccolo as well.

The PR contains very verbose explanation of these changes as well as use case examples.

I find it weird that from_lua_multi can take any number of arguments without telling the caller how many were consumed (which can be ignored if not needed). I do see that it's only really intended for function arguments and Variadic is just a nicety that comes from it, but given that something like this greatly improved DX on my project I think it could be a useful to others as well.

Hey there! We're considering using piccolo in Jumpy and as I was just browsing and playing around I realized that __newindex isn't implemented yet. We'd probably need that as a way to create proxy types that let us hook into variable assignments.

I might be able to implement it myself, and there's still a chance we don't end up using piccolo or we don't get to testing it out just yet, but I figured I'd open an issue to put it on the radar and see if there was anything I should know if I tried to implement it.

I noticed in c78bdf8 all the files from the official tests were added.
But they're also available at https://github.com/lua/tests, so maybe a git submodule would be better?
(feel free to close this issue if it's not worth the trouble)