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.
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.
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
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.
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.
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.
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!
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
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
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