@Derayne I have the same issue, turning João into Jo. Hoping this can be fixed in the next build:

[000000 000] Starting Picotron 0.1.0
[000000 000] build: 240315-191035
[000010 000] creating process [root]
[000039 001] mount: [/] [C:/Users/Jo]
[000039 001] PF_HOST file not found: C:/Users/Jo/system/boot.lua
[000070 001] PF_HOST file not found: C:/Users/Jo/.info.pod
[000464 001] Reading controller mappings: C:/Users/João/AppData/Roaming/Picotron/sdl_controllers.txt
[000464 001] searching for joysticks
[000464 001] found 1 joysticks
[000464 001] connecting joystick 0
(...)

I've been unable to run any carts downloaded from the forum. Every cart gives the same error.

@wandy_dev It doesn't like hyphens in the filename. Take those out and it'll work.

Okay, this is getting too meta:

Even this thread is exhibiting bugs now. Great!

On Windows 11, with trackpad, trackpad in "tap" mode. Single tap works, double tap does not. Double "Click" (pressing down on the trackpad to engage the switch, as opposed to the tap), does work.

Fetch cant fetch urls with capital letters. Trying to send a url with a base64 parameter, but the url seems to be being changed to lower case before its sent out.

@MBoffin That solved my issue. Thanks

In /system/lib/gui.lua, there is a typo on line 212, in the attach_field function:

str = type(self.get == "function") and self:get() or "---"

should, i believe, be:

str = type(self.get) == "function" and self:get() or "---"

the result of this is that type(self.get == "function") becomes type(false) which becomes "boolean" which is a string that contains something, therefore is interpreted as a truthy value, therefore never returning false.

this leads to attempted use of GuiElement:attach_field failing a get/set is not provided. obviously a limited issue. but, it's a validation failure, so i thought i'd point it out

Flipping sprites seems very broken near the edges of the screen:

This is a fun little bug without any real consequences:

When moving items on the desktop to the left side, the label starts to cut off from the right (drive.loc becomes "drive.lo", "drive.l" etc. the further it is to the edge).

(edit: rewritten for clarity)

The Code Editor now seems to try to be two things at once: It allows to edit the code of the cart in ram (/ram/cart), but we can also edit additional files from other carts or single lua files. This new flexibility is great, but also leads to some confusion (at least for me).

Feature request(s):

When more than one file is opened with the same name, it is impossible to know which one is saved to a specific path without saving it. It would be great if the full path(s) that a tab is associated with could be shown somewhere when hovering over a tab.
Additionally, it could be useful to mark the tabs for the cart currently in ram with an icon or a different colour to show which will be relevant to executing the current cart with Ctrl-R.

Potential Bug:

Although the editor generally detects when I try to open the same file twice, a cart that is in ram (/ram/cart) and also saved to some location (/desktop/mycart) will have the main.lua file be written to both locations.
Opening the file from the terminal for each location results in two tabs that compete with each other:

> save /desktop/mycart
> open /ram/cart/main.lua
> open /desktop/mycart/main.lua

When the main.lua file is opened from /ram/cart/main.lua and the user presses Ctrl+S, the file is saved to /desktop/mycart/main.lua
When the file is opened from /desktop/mycart/main.lua and the user presses Ctrl+S, the file is saved to /desktop/mycart/main.lua#1

There is also currently no clear way on how to make a clean new cart without restarting picotron.

The btn call acts very strange with the joystick where if I were to program

P1.x += btn(1)/125.5 - btn(0)/125.5

It would return the error: “attempt to perform arithmetic on a Boolean value”
Even though btn(1) and btn(0) both return numbers.

Some other things that may be of importance are that I am using the Linux version on my steam deck, and that I could not find startup.lua in my files.

Hey All, thanks for the reports, and extra thanks @thattomhall for managing to save the forum from being flooded with bug threads!

I've made a first pass at many of the issues here with 0.1.0c which is live now, but will comb through again shortly for 0.1.0d, so by all means keep the reports coming. Please mention which version of Picotron you're using (you can check on the boot screen or from the Picotron menu -> About Picotron). And if it does seem like an issue that could benefit from a separate thread, please go ahead but either way I'll see it.

There are still some outstanding issues in 0.1.0c I'd like to get resolved soon: most notably the unexplained hard crashes on Mac (couldn't actually reproduce myself though), and the incorrect handling of user folder paths.

p.s. I'd just like to acknowledge the indignity of posting this on my own bbs software which is also visibly very broken.

I don't think it was posted yet, but when copy and pasting in the code editor seems to temporarily produce characters that mess with the x position of the text. Specifically at the end of the lines of text, except for the last line.
By copying and pasting:

aaa
bbb

and then placing the cursor after aaa, typing any characters will be placed at the very left.

loading the file again will get rid of the bug.

> Picotron menu -> About Picotron

I got a micro report @zep: it still shows the b version.

Also I've got a bigger one: the map function doesn't work anymore ? Calling it with the default arguments doens't work anymore

EDIT to avoid cluttering: Looks like fetch doesn't work in a script's top level but works if I create a global in _init

hi! I'm on 0.1.0c, and it looks like fetch no longer works with urls as far as I can tell; it just gives me a string of a number that increases each time I try to fetch that url

Seems like Keyboards with "ALTGR" Key are not working anymore in 0.1.0c Cant type some symbols like "\" "|" "@" "#" ...

Spanish QWERTY Keyboard in my case.

On _init(), I think the draw target is not set or initialized, so it can't be drawn to and things like print() will return nil instead of any values.

I worked around this by creating temporary userdata and setting it as the draw target.

Since text editors don't receive input by default (good change), some system apps like About are broken now

nevermind on my fetch issue! apparently you actually just need to put it in a coroutine (I thought the changelog meant that it now ran as a coroutine on its own)

I know 0.1.0c doesn't have the hard crashes on mac fixed yet but they do seem to be a bit better.

In case it's helpful- for me the crashes always happen maybe 10-15 minutes after I've arrowed over (four-finger dragged) to another workspace/desktop out of Picotron. So I guess it's when it has been running in the 'background' for a while.

Okay I'm on macOS Sonoma 14.3, M2 mac. I'm still having the exact same crashing issue on 0.1.0c. It happens like clock work every time. My Picotron will crash exactly 13 minutes and 20 seconds after start up. It doesn't matter if I stay completely idle or if I'm actively working on something. I have recreated this 5 times on 0.1.0b and now twice on 0.1.0c. Picotron starts out using 104MB on the mac activity monitor, and always crashes around the upper 500MB mark. (usually 540-580MB). It stays around 40% CPU usage (highest on my mac) at 13 threads. Don't know if any of this is useful. My current workaround- Set a timer for 13 minutes and hit it with a good ole "save" command before it crashes.

Edit: Added the log.txt data from the crash when using the function printh(time())

[000000 000] Starting Picotron 0.1.0c
[000000 000] build: 240325-051148
[000005 000] creating process [root]
[000009 001] mount: [/] [/Users/jaronyankey/Library/Application Support/Picotron/drive]
[000382 001] Reading controller mappings: /Users/jaronyankey/Library/Application Support/Picotron/sdl_controllers.txt
[000382 001] searching for joysticks
[000382 001] found 0 joysticks
[000382 001] ok
[000506 001] creating process pm
[000507 001] creating process wm
[000509 001] creating process code
[000510 001] creating process gfx
[000512 001] creating process map
[000514 001] creating process sfx
[000515 001] creating process patchwork
[000517 001] creating process tooltray
[000518 001] creating process clock
[000519 001] creating process eyes
[000520 001] creating process terminal
[000943 003] creating process filenav
[001166 003] creating process filenav
[002730 001] @@ finished_boot_sequence = 1
[007556 012] creating process load
[007580 015] creating process open
[007591 016] creating process code
[007593 016] creating process gfx
[007595 016] creating process map
[007597 016] creating process sfx
[013539 003] creating process terminal
[190474 003] creating process breach
[417741 021] run_process_slice() for process 21 error: 2 :1021: stack overflow
[417741 021] --------
traceback:
stack traceback:
    :1021: in function 'coresume'
    /system/apps/terminal.lua:85: in upvalue 'run_cproj_callback'
    /system/apps/terminal.lua:524: in function '_update'
    /system/lib/foot.lua:53: in local 'func'
    :880: in function 'include'
    terminal:33: in main chunk
---------
[417742 021] SYSTEM ERROR: *runtime error
[417742 021] SYSTEM ERROR: :1021: stack overflow
[417742 021] SYSTEM ERROR: stack traceback:
    :1021: in function 'coresume'

[810499 001] run_process_slice() for process 1 error: 2 :137: stack overflow
[810500 001] --------
traceback:
stack traceback:
    :137: in main chunk
---------
[810500 001] SYSTEM ERROR: *runtime error
[810500 001] SYSTEM ERROR: :137: stack overflow
[810500 001] SYSTEM ERROR: stack traceback:
    :137: in main chunk
[810500 001] ** RUNTIME ERROR IN KERNEL **
[810500 001] :137: stack overflow

Attempting to index a string (example: ?("abc")[2]) returns nil.

I don't see this reported, but on 0.1.0c it seems like MAP doesn't draw a map anymore? I tried with no params, and using the Pico-8 format, but can't get MAP (or MSET) to show anything. MGET reports the correct tile, but nothing is displayed. Maybe the API changed?

[EDIT: ah yeah, Eiyeron already reported this above]

M1 Mac, MacOS 14.3, Picotron 0.1.0c

• @Jaron_Y I hadn't thought to time the crashes, but I just did (twice) and you're right - pretty close to 13 minutes 20 seconds. And, yeah, Activity Monitor does seem to suggest that Picotron might be leaking.
• Doing many things with nil produces a hard crash: calling it (asdf()), doing arithmetic on it (5 + not_a_var), indexing it (doesnt_exist[1]). This happens both for literal nil and for things that evaluate to nil.

log.txt contains the following lines after the 13:20 (800s) crash:

[811478 001] run_process_slice() for process 1 error: 2 :137: stack overflow
[811478 001] --------
traceback:
stack traceback:
    :137: in main chunk
---------
[811478 001] SYSTEM ERROR: *runtime error
[811478 001] SYSTEM ERROR: :137: stack overflow
[811478 001] SYSTEM ERROR: stack traceback:
    :137: in main chunk
[811478 001] ** RUNTIME ERROR IN KERNEL **
[811478 001] :137: stack overflow

had a weird issue on upgrading to 0.1.0c, couldn't load any carts from the bbs and the libs were acting weird (couldn't get the fetch to work right with coroutines and my windows were freezing in a really weird way).

I fixed it by deleting the system folder and starting picotron again

In Picotron 0.1.0c, MacOS 14.3.1, experiencing the same Mac crashes others are.

Also experiencing the lack of map() working. I've tried explicitly loading a different map and trying to display it, and trying both default 16x16 tiles and 8x8 tiles imported from PICO-8 using the (appreciated!) new feature that reads the first image from the .gfx file for the tile size, and neither worked. Tried several combinations of just map() and map called with various parameters. Seems to just fail to display anything with no error in all cases.

Hello everyone, hello zep !
Picotron seems amazing !!

French Keyboard here
most keys seems binded correctly but some of them are not working.
() {} # ~ are the characters I can't use right now
Also even if AZQW are binded properly CTRL+A CTRL+Z CTRL+Q or CTRL+W are binded like if I had and english keyboard.

Hello Benjamin.

Seems like there's undeed a regression for Azerty keyboard as alt-gr is not properly handled anymore. Meanwhile, you can still use an external editor if you're storing your cart as a folder (or a .p64 if you feel brave enough).

Regarding the shortcut mapping, zep added a way to customize the mapping in the doc. Does that fix the issue?

I am running into issues with mget:

• Unlike pico-8 accessing a tile outside of the map returns nil instead of 0, so now all code that uses mget needs to do additional checks to avoid crashing. Not sure if this is intentional but nil is not exactly providing any useful information that can't just be obtained in more straightforward ways.

• Maybe I'm missing something but passing a map as the first argument to mget the way I would do with map doesn't seem to work, I think it's always returning tiles for the default map?

@Eiyeron @benjamin_soule @zep

if it's what you meant, I've tried store("/appdata/system/scancodes.pod", {ralt=230}) but when typing right alt (altGr) I still got in the console: "skipped alt entry"

About accented letters (such as "é", "à"), I can't reassign them because it's not supported at all in picotron. If it's not supported, I'd prefer they don't produce anything instead of those 2 squares, one before the prompt, one after ("[][]"). In TIC-80 unknown non-ascii characters are simply ignored, it should be the easiest for handling that.

Btw as stated in the picotron doc, to handle correctly on AZERTY ctrl+A, ctrl+X and such, I only had to type:

store("/appdata/system/keycodes.pod", {a="q",z="w",q="a",w="z",m=":",[":"]="<",["<"]="m"})

well #picotron 0.1.0c update: Nice, the map() draw nothing. What we have to do? BTW, I just discovered that the {} and [] caracters on keyboard not responding as in code editor and terminal.

@BGelais it's working for me, I'm manually specifying the map data:
map(world[1].bmp) where the map is loaded earlier world = fetch("./map/green_hill.map")
It's not exactly intuitive but it works

altgr isn't detected on my keyboard on 0.1.0c. It used to work on the previous version. For example, to type "/" I have to press altgr + q on my keyboard. I currently can't type / on the code editor or terminal.

I just discovered that the {} and [] caracters on keyboard not responding, including other AltCar's as in code editor and terminal. Bug fixes give new bugs! :P

System: macOS Sonoma 14.4 (Intel)
Issue: Picotron closes on its own with no error after 14 minutes.
Version: Picotron 0.1.0C

Picotron version 0.1.0C still closes on its own after 14 minutes. There is no error shown when it closes.

First - I am loving Picotron. So excited that it's finally out!

Second - I am on macOS 14.3, M1. This instantly crashes Picotron 0.1.0c for me, no notable output in the log file:

local ce

function _draw()
    g:draw_all()
end

function _update()
    g:update_all()
end

function _init()
    poke(0x4000,get(fetch"/system/fonts/lil.font"))

    window{
        width = 280,
        height = 200,
        title = "PxxxXxxx"
    }

    g = create_gui()
    ce = g:attach_field({})
end

I also see crashes if I supply get/set and a number of other variants, this is a minimal test case.

Found more macOS bugs :P
Picotron doesn't abort processing input once it's been captured by the operating system, for example the globe key + f (or fn + f on old macs) shortcut which toggles fullscreen for a window works but picotron inputs "f" into the text editor or terminal. It's probably not the best idea to directly read the keyboard, since it's not accounting for different keyboard layouts or system shortcuts.

Version 0.1.0c. Mac OS 12.5 intel core
Still crashes in music editor. It runs fine when I stay in the instrument section, but crashes without notice as soon as I start making a melody in SFX.

Update: Also crashed in code editor after hitting backspace three times (don't know if it has anything to do with it), and noticed it crashes after I leave it in background for a while.

I generated a MacOS crash report using the XCode "leaks" tool:

https://drive.google.com/file/d/1TFsLFU8-9ZpOlFvTR78lU9ixUR8oTg2S/view?usp=sharing

I wasn't doing much with Picotron to get this to happen. Crashes seem to happen when idling at the desktop. I let it run the bunny screen saver for part of this session, but I don't know if that affected the crash condition (lessened, worsened, or neither). The desktop had been visible for a while when the crash occurred.

I don't know much about the "leaks" tool. Please let me know how else I can help. I'm happy to run test builds on my machine. I'm eager to get the Mac crashing issues resolved!

Here are some more gotchas/general notes from 0.1.0c on macOS. Many of them ate a lot of time to debug. Most can be avoided with better error messages/error handling.

Some useful techniques first:

• Run from lldb and you can a) quickly restart on crash by typing run and b) see log output which often includes key lua exception info. printh output also appears. If you breakpoint on exit and _exit you can get callstacks on "clean" fatal exits, too.
• I really got a lot of use out of @NuSan's API reference tool, #function_tool-2 from https://www.lexaloffle.com/bbs/?tid=140783 . I really liked that it pointed me to system library code.
• This thread was super useful, also: https://www.lexaloffle.com/bbs/?pid=143405

Onto the gotchas:

• global scope code exceptions seem to often crash picotron, but if the same code goes into a function you often get a useful error.
• If you call get_display() before you have called window, you get a nil result. Probably should throw an error like "hey dummy no display"?
• Text input widget requires you give it keyboard focus before it works (and you can't click on it to assign focus). You CAN double click to SELECT text, however, which makes it seem like it's almost working. This ate a lot of time.
• Selecting text is weird without also taking focus... I was trying to make a login screen with a username and password and couldn't get it to act in any sort of natural way because of this. I think I could have put a widget on top of the text edit controls and intercepted clicks there to set the focus but I gave up before then?
• If you quit a windowed app which you launched via ctrl-r, by hitting escape, the window becomes a terminal. This appears to happen to all apps (even system ones) run via ctrl-r, so I think it's fine to ignore?
• click and other event handlers don't seem to work on field or text editor widgets, because these widgets already use them. (I tried this in order to be able to click on a text field to set its keyboard focus.) Some way to either detect and error, or allow overriding, would be really useful.
• printh would have been super cool to see in the bottom-of-screen error window.
• I think there's a way to run terminal commands at startup which I saw mentioned once but never saw again. A txt file somewhere? Then I could have put load mygame.p64 at startup and been able to quickly resume dev work upon crash.
• As mentioned elsewhere, it was easy to lose track of what files multiple main.lua tabs referenced.

The stack for crash @ 15 minutes, seems to be consistent across multiple runs:

* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 2.2
  * frame #0: 0x0000000181e99cf4 libsystem_c.dylib`exit
    frame #1: 0x0000000100073854 picotron`run_process_slice + 944
    frame #2: 0x00000001000528c0 picotron`main + 436
    frame #3: 0x0000000181c5d0e0 dyld`start + 2360

I get what looks like the same output as everyone else in log.txt:

[614604 003] creating process save
[824389 001] run_process_slice() for process 1 error: 2 :137: stack overflow
[824389 001] --------
traceback:
stack traceback:
    :137: in main chunk
---------
[824389 001] SYSTEM ERROR: *runtime error
[824389 001] SYSTEM ERROR: :137: stack overflow
[824389 001] SYSTEM ERROR: stack traceback:
    :137: in main chunk
[824389 001] ** RUNTIME ERROR IN KERNEL **
[824389 001] :137: stack overflow

Overall I like the GUI library and hope to see it grow. With some care it could grow into a tight, fun little framework... Strong Amiga/System 7/Mac OS 8 vibes.

@bengarney pressing escape doesn't make your program become a terminal, running the current cart starts as a terminal in the first place — you can see that the about menu is showing the terminal instead if your cart.

I created a small script in Picotron that displays the last keyboard keys pressed to check what is happening to ALTGR, I can see that ALTGR is indeed detected... or something like that. In version 0.1.0b and earlier, it's detected as a combination of CTRL and ALT (As it should be), and then when pressing the key of the alternative character we want to write in the editor , it writes. In version 0.1.0c, ALTGR is still detected as CTRL+ALT, but it doesn't detect the functionality of CTRL+ALT to write the alternate characters

If you are interested, this is the simple key testing script

-- CTRL is key(224)
-- RALT is key(230)
-- ALTGR should be key(224)+key(230)
function _draw()
    cls(1)
    print("Press a key:")
    for kp = 0, 255 do 
        if key(kp) then 
           print("Pressed key("..kp..")") 
        end
    end
end

for some reason, very randomly it seems, the window for picotron on the bbs will appear smaller, if it means anything im using opera gx.

In v0.1.0c I cannot edit the "about" of my cart.

And the triplane wallpaper has disappeared.

Windows 11 v0.1.0c it appears the map() function is not drawing the map to the screen.