~phoebos

https://bvnf.space

~phoebos/uxndebug

Last active 2 years ago
View more

Recent activity

Re: Offpunk packaging 1 year, 4 months ago

From phoebos to ~lioploum/offpunk-devel

On Mon, Oct 02, 2023 at 12:17:54 +0000, Riteo Siuga wrote:
> I'm just a bit confused about the actual problem though, why can't the
> individual pieces just be exported as "dumb" executables, with a nice
> `#!/usr/bin/python3` shebang on top?

I think they're not just executable programs, but a mixture of program
and library in each file, so the problem is with `import`ing modules. I
would have thought that the best way would be to make one library file,
which is installed to the default library location, and then each
interface is one file in $PATH which imports the library. Maybe that's
not possible in Python.

Re: [PATCH 1/2] Provide manuals for new commands. 1 year, 5 months ago

From phoebos to ~lioploum/offpunk-devel

On Sun, Aug 27, 2023 at 22:33:50 +0200, Étienne Mollier wrote:
> +.Os Debian

Not sure you meant to include these.

Re: [PATCH v2] switch to a PEP517 build system 1 year, 11 months ago

From phoebos to ~lioploum/offpunk-devel

On Sun, Mar 12, 2023 at 11:47:38 +0500, Anna (cybertailor) Vyalkova wrote:
> Flit is the simplest of PEP517 build systems so I used it.

There is no "build" step for offpunk.
Flit's own rationale [1] claims that installing a simple Python project
with no compilation steps is *not* as simple as copying a file to the
right place. Why is this the case for offpunk? The only reason this
might not be the case is if offpunk were used as a module by anything
else (which I don't believe it is).

[1]: https://flit.pypa.io/en/latest/rationale.html

If Flit is used so that offpunk can be uploaded to PyPI, is that really
a step that has to be used in every user's package installation? (I'm

Re: Man page for offpunk 1 year, 11 months ago

From phoebos to ~lioploum/offpunk-devel

On Mon, Mar 06, 2023 at 20:58:45 +0000, Ploum wrote:
> >I was not aware of mandoc(1) and the mdoc(7) format.  This
> >approach is also quite appealing, especially in the case Ploum
> >were to consider the manual page as a standalone document
> >instead of an autogenerated one.  The dependency tree of mandoc
> >is also very light weight: the libc and the libz.  This package
> >is already available in Debian, should I need it to proceed to
> >the packaging of offpunk.

Note that groff also supports mdoc(7); mandoc is not necessary.

> Thanks for all the inputs. I really think mdoc is the way to go. I
> should take the time to learn it and produce a first version.

Re: Man page for offpunk 1 year, 11 months ago

From phoebos to ~lioploum/offpunk-packagers

On Mon, Mar 06, 2023 at 20:58:45 +0000, Ploum wrote:
> >I was not aware of mandoc(1) and the mdoc(7) format.  This
> >approach is also quite appealing, especially in the case Ploum
> >were to consider the manual page as a standalone document
> >instead of an autogenerated one.  The dependency tree of mandoc
> >is also very light weight: the libc and the libz.  This package
> >is already available in Debian, should I need it to proceed to
> >the packaging of offpunk.

Note that groff also supports mdoc(7); mandoc is not necessary.

> Thanks for all the inputs. I really think mdoc is the way to go. I
> should take the time to learn it and produce a first version.

Re: Man page for offpunk 1 year, 11 months ago

From phoebos to ~lioploum/offpunk-devel

On Fri, Mar 03, 2023 at 14:48:18 +0000, Ploum wrote:
> But one point needed for a Debian package is a man page. Étienne created
> one here:
> https://salsa.debian.org/python-team/packages/offpunk/-/blob/debian/master/debian/offpunk.1
> 
> But I feel it would be a lot better to maintain our own upstream
> manpage.

Manpages are essential in my opinion. Étienne's manpage is written in
man(7), the historical markup in which you use formatting to describe
syntax. I prefer mdoc(7), which uses _semantic markup_ which is then
formatted consistently. mdoc is designed to be easy to write. It is just
as portable as man, and generally better documented.

Re: Offpunk on MacOS 2 years ago

From phoebos to ~lioploum/offpunk-devel

On Sun, Jan 08, 2023 at 10:52:47 +0000, Ploum wrote:
> What do you think? Are small and frequent release better than big and
> less frequent releases? (I’m thinking about packagers here)

There are some projects which make a new release on every commit, which
is annoying. I think that as long as a release is made for a reason,
it's fine even if it's only one new patch or feature.

Happy new year!

Re: Synthesizable Uxn CPU 2 years ago

From phoebos to ~rabbits/uxn

On Thu, Jun 30, 2022 at 15:42:59 -0700, Hundred Rabbits wrote:
> Could you explain the k mode in your own words in that way that could
> be useful to other implementers, so I could put it on the docs? Is
> there a way we could make the uxn.c more explicit?

I'm not Martin, but my own thoughts: (pretty much a translation of uxn.c):

Normally, operations get values to work on by POPping sequentially, but the
k mode causes POP to do nothing to the stack, or it POPs from a copy of the stack.
So any operation which needs to read some value, even if it will leave it there,
would usually

    a = POP(); PUSH(a);
    ...other operations using a

Re: File device and the debugger [was Re: Seeking the File device] 2 years ago

From phoebos to ~rabbits/uxn

On Wed, Jun 22, 2022 at 17:21:38 -0700, Hundred Rabbits wrote:
> just wanted to say thanks for the sandboxing patch, works amazingly
> well. I've been testing it for the past two days and I haven't found a
> way to exit it.

That's great to hear! I spent almost a full day on it so it's nice that
it's appreciated. Unfortunately it might require some rewriting if/when
the File devices are changed.

phoebos

Re: File device and the debugger [was Re: Seeking the File device] 2 years ago

From phoebos to ~rabbits/uxn

On Wed, Jun 22, 2022 at 01:01:18 +0100, Andrew Alderwick wrote:
> I wonder what the appetite is to restrict it further so that if it's run in
> the home directory, it changes directory to e.g. ~/.config/uxn after reading
> the ROM. My threat model here is that running Uxn from inside ~/uxn is
> safer, but when it's run directly in ${HOME} then it can read/delete my
> ~/.ssh/ private keys.

On second thought, this would be quite confusing behaviour to any program
using the File device. Perhaps a better method would be to include in
the emulator code a list of paths which are forbidden to be accessed,
such as $HOME/.ssh . This list could be hard-coded or read from a file.
We'd have implemented something like unveil(2) (but the opposite!).

phoebos