Files library - "file names" block is returning: [empty list]

Issue #169 resolved
connochaetes created an issue

Hi.

This issue is a follow up to this one: https://bitbucket.org/john_maloney/smallvm/issues/167/bmp-library-file-upload

I successfully sent three files to my Citilab ED1 as described in the mentioned issue. ( @ José García : Thanks ) Right now, I’m using the “Files” library. The block “size of file …” is working fine: It’s returning the sizes of the files on the board. Sadly, the “file names” block is saying: [empty list] Any suggestions? (Since there’s plenty of space on the board, it’s a minor issue for me.)

Comments (6)

  1. John Maloney repo owner

    This sounds like a bug in the file enumeration. What are the names of the files?

    Also, what version of the VM firmware are you using? (Just checking that you have the latest, which is v100.)

    If you’d like to help debug this, you could right-click on the ‘file names' block ans select ‘show block definition’. That function uses two key block: ‘start file list’ and ‘next file in list’. Pull out duplicates of those two blocks. Click ‘start file list’ then click ‘next file in list’. I’m guessing that will return an empty string, which doesn’t get displayed (so the block appears to do nothing). You could put the ‘next file in list’ inside a ‘length of’ block from the list category to confirm that it’s length is zero.

    If you get a non-empty string back from ‘next file in list’ then something else may be wrong. But my guess is that ‘next file in list’ is failing for some reason. It could have something to do with the file names but more likely it’s just a bug in the enumeration code.

  2. connochaetes reporter

    The files names are “kst.bmp” (67722 bytes) and “test.bmp” (65674 bytes). The firmware version is “MicroBlocks Virtual Machine v100 Citilab ED1”. I followed your instructions and clicked the blocks “start file list” and “next file in list”. As you expected “length of ‘next file in list’” returns a zero. So, you guessed right. Anyway, the problem remains the same. (Again: for me, it’s a minor issue. But I think, it should be fixed at some point.) Thank you, so far.

  3. John Maloney repo owner

    Thanks for the info. Those seems like perfectly normal file names. I’ll try to reproduce it…

  4. Log in to comment