paths

[carl0sgs]

Ok great :-)
I think you should post the function once done, since it sounds helpful :-P

how's it going on your multitasking thing? Looks amazing. There is also another big project, very similar: NanoDesktop, but as far as I can see your one looks nicer (althou' I would change a bit the graphics, but this is no issue), and faster. Keep the good work up.

I have really done almost nothing after the last release (due to so many exams), but I've been thinking a lot about how next version is going to be.

It will use OSlib and, if everything goes as expected, it will have widgets (buttons, textboxes... etc), and eventually simple 3D support.

Cheers!

[Alberto]

I think you should post the function once done, since it sounds helpful :-P

I'll certainly do. Just few days to see if I can also get the relative paths work for different devices, storing them during chdir's.

I have really done almost nothing after the last release (due to so many exams), but I've been thinking a lot about how next version is going to be.

It will use OSlib and, if everything goes as expected, it will have widgets (buttons, textboxes... etc), and eventually simple 3D support.

don't forget to allow access to the whole screen, not only windows... this was a big (for graphic impact) limit of previous releases of that NanoDesktop. BTW, you can have a look at it here:

http://visilab.unime.it/~filippo/Nanode ... nloads.htm

there is also a virtual machine for VirtualBox already set up and configured, so you can get your hands on very quickly.

Cheers, A.

[carl0sgs]

I'll certainly do. Just few days to see if I can also get the relative paths work for different devices, storing them during chdir's.

Great! Thanks :-)
I think it is a needed function that is usually replaced with an "easy fix", but it is definitely much more elegant and stable this way.

don't forget to allow access to the whole screen, not only windows... this was a big (for graphic impact) limit of previous releases of that NanoDesktop.

Ok I wont forget. The way I'm going to program the new version should make that very easy. (Main screen is a window -the main window- which can be "replaced" by another window). Also, resizing windows should be possible since they won't work with image buffers anymore (only widgets and objects).

BTW, you can have a look at it here:

http://visilab.unime.it/~filippo/Nanode ... nloads.htm

there is also a virtual machine for VirtualBox already set up and configured, so you can get your hands on very quickly.

Yes I have seen NanoDesktop, but since I'm in Linux I haven't been able to program anything for it.

Cheers!

[jimparis]

assumed: we run from "host0:/TEST/"
1. "test.txt" gives "host0:/TEST/test.txt" CORRECT
4. "host0:/test.txt" gives "host0:/test.txt' CORRECT
3. expanding "ms0:/test.txt" gives "ms0:/test.txt" CORRECT
3. expanding "ms0:/../test.txt" gives "ms0:/test.txt" CORRECT

Yes, these are all working as expected

2. "./test.txt" gives "host0:/TEST/host0:./test.txt" WRONGGG!

I don't believe this -- it works fine in my tests, and returns "host0:/TEST/test.txt"

3. "host0:test.txt" gives "host0:/TEST/host0:test.txt" WRONGGG!
1. expanding "ms0:test.txt" gives "host0:/TEST/ms0:test.txt" WRONG!
2. expanding "ms0:../test.txt" gives "host0:/TEST/ms0:../test.txt" WRONG!

Relative paths with a drive specification won't work. There's no concept of a "relative path on a drive" because unless you've actually switched your working directory over to that drive, there's nothing for it to be "relative" to. This could be extended to handle the case where the drive is the same as the cwd drive, but adding special cases is weird and I think the format "drive0:relativepath" just shouldn't be used.

From the PSP's libc point of view, valid paths are:

• full absolute path with drive

  Code: Select all

  drive0:/path

• full absolute path without drive:

  Code: Select all

  /path

• relative path without drive:

  Code: Select all

  path

and these will all get normalized correctly. Feel free to post a patch extending the format to other varieties, but you'll have to convince us that they make sense.

[Alberto]

Yes, these are all working as expected

indeed, no complains for these.

2. "./test.txt" gives "host0:/TEST/host0:./test.txt" WRONGGG!

I don't believe this -- it works fine in my tests, and returns "host0:/TEST/test.txt"

it was the very first test I've made, as I use this a lot, and was amazingly surprised it worked opening a file specifying the relative path, but gave a strange result expanding it.
I'll try it again for sure, maybe today if my little baby falls to sleep a couple of hours in the afternoon... ;-)

Relative paths with a drive specification won't work. There's no concept of a "relative path on a drive" because unless you've actually switched your working directory over to that drive, there's nothing for it to be "relative" to. This could be extended to handle the case where the drive is the same as the cwd drive, but adding special cases is weird and I think the format "drive0:relativepath" just shouldn't be used.

From the PSP's libc point of view, valid paths are:

• full absolute path with drive

  Code: Select all

  drive0:/path

• full absolute path without drive:

  Code: Select all

  /path

• relative path without drive:

  Code: Select all

  path

and these will all get normalized correctly. Feel free to post a patch extending the format to other varieties, but you'll have to convince us that they make sense.

ok, I see, and was actually thinking what the concept of relative paths across drives should be.
I think I've been teached wrongly... and still pretend to use these ugly things ;-) in the old DOS days, where you could do a

Code: Select all

"CD D:\TEST\FIRST"
"CD E:\DATA\SAVES"

and then use relative paths just with "D:testfile.txt" or "E:1001.dat". Expanding them resulted accordingly to the "cwd" of each drive.

Maybe this gets no sense at all, since on the PSP (and in Linux, even if no concept of drive applies) cd-ing to a different path simply makes it the cwd, and you cannot switch among paths unless you do a new cd, and thus changing the cwd that would explode the relative path.

I'm going to consider only the valid specs from libc, and eventually fix the (according to my tests) wrong behaviors.

Then, if it is allcorrect and makes sense, we can think about a patch.

Thanks all for following me along the "path" ;-)

Have you all a nice day.

Cheers, A.

[Alberto]

ok,

finally, considering what is a relative, absolute and with or without drive for the libc, and having performed a bunch of tests with different paths (I guess I covered all the possibilities...) I see __psp_path_absolute perfectly suits my needs.

Anyway, talking a bit about it has been nice.


Cheers, A.