Jump to content
Muxe Inc Forums
Sign in to follow this  
Guest JClu

ndn_3_00_0004_l64 doesn't start within tinycore 11.1

Recommended Posts

Garl    0

ascii art with single and double lines work fine for me

image.png.26f295ac06c78ad76315ba5f2c9bb3c5.png

Share this post


Link to post
Share on other sites
Guest JClu   
Guest JClu

Really? with the same version you provided me with? Wow!

  Well, I guess I'll have to deal with the terminal conf
     though i even put lxterminal, locales in UTF8 and some inernatl fonts...
     -sigh- gotta dig deeper i guess. not easy with limited time, age and skills :-)
     but were would the fun be? it the reason why i chose TinyCore :
      to have the bare minimum and DIY + enjoy the CPU spare from the bloat of other distros (ubu* being just another wdoz)

  thank you for giving it the possibility to blossom in linux,
    plus you give me a nice alternative to my current only choices :
    mc for TUI and dcmd on GUI (BTW, dcmd is also devd in Pascal and russian... is it a coincidence?  :-)
JClu
PS: what the mention inconvenience i mentionned earlier : about the letters assigned to ALL mount points?
       I mean, to avoid the loop devices, unless explicitly asked. possible? cpacibo. dobri dien.

Share this post


Link to post
Share on other sites
Guest JClu   
Guest JClu

Hi Garl,
  Yes! now it really gets usable to switch "drives" with 'alt+F1' or 'alt+F1'
   (though 'alt+left' and 'alt+right' are not responding the expected way :
     there's a 'dir change history' popup showing current dir but nothing changes) or even usingthe mouse : Thank you!

  As for the lines drawing, the way i see it, the ball is on my side and i got to figure out how to handle all I/O on terminals solving any key (combinations) inputs and charsets display problems. If i want to

  tinycore(TCL)? if you are already using a distro and are happy with it...keep using it! It's not to prevent you to come to the dark side but rather to make sure you put your energy into ndn rather than disco

   Now, before you put your mind into it i'm going to tell the + and - i see in it (my experience/opinion) :
  i've got acquainted with slackware  when in its v2 (about 20 floppies to install!) ...fast-forward
  After tasting live linux in the form of demolinux (made @ PVI university along side DNX demo on a floppy)
  a soon later puppylinux... i could not go back installing distros anymore. Knoppix and many other came : HUGE!
  FFward again to nowadays and only a few distros respect the meaning of the word lightweight
    for x86_64 archi in decreasing size of main branch of the general purpose distro :
     GRML (<300+~700+MB), slax|porteus (<300MB),
     puppy (<200MB), alpine (<150MB),
     slitaz (<60MB), tinycore (<20MB)
  there are some specialized distros out there that could join :
    in VoIP astlinux (a semi-live distro with asterisk <100MB)

  now, why did i end up with tcl?
  the "+"
    size (easy/fast boot on haedware and in qemu(run in tcl :-)),
    extensions (thus the problem of the 'loop devices') like the modules from slax = "live (un-)mount the whole app pkg",
    and their repo has most i need (bbox, tmux, mc, elinks...)
  the "-"
    well since the community isn't big, you can find yourself on your own when trying to solve problems that are too specific :
    i asked to have LXC pkg (and kernel ready) available back in version 3+... not done yet in 11.1
    i like its poweroff backup(persistence), and sleep2ram is easy... but hibernation isn't there (of course own scripts and...)

  maybe you'd like slitaz and it's web configuration+pakg managmt but its persistence system is not as efficient as in tcl

  the others... their weigth (though alpine musl nased adds security, a rich pkg base...)

  well, so the choice depends much on :
    you goal, your current skills and the resources available (time&money included).

  however, thank you for mentionning it as it really shows how dedicated you are as a dev.
  as for ndn i've known it when its grand-pa dn prior to v1.51 was coming out of Rit-labs(and their email cli:-)
  so, seing it under linux (even with its too fast tetris) touchde me with nostalgia (no sudoku yet?)

  i have a lot of suggestions but prefer to focus in having it running correctly so
    i can use it instead of mc (to many script configured to drop it easily).

thank you again,
  as soon as i get it correctly running i report here with the findings (or if i meet some unexpected roadblock)

JClu

 

Share this post


Link to post
Share on other sites
Garl    0
On 23.10.2020 at 0:07 PM, Guest JClu said:

Yes! now it really gets usable to switch "drives" with 'alt+F1' or 'alt+F1'

image.png.afd257900ae3e9bc831a396b98002395.png

image.png.1067ffa1938eec7198895655c46762ee.png

is NDN run on your TinyCore?

 

Share this post


Link to post
Share on other sites
Guest JClu   
Guest JClu

Hello Garl,
  as for ruuning ndn on TCL... well that's my only OS for about 2 years so yes else i would have not been able to perform the previous tests.
  here the screen ib text mode (easier for copy/paste an lighter :
 

[20201025 7 07:53:56]{tc@bsrv:/mnt/sda2/data/Downloads/-- ndn/ndn_lin/nightly_l64}
$ uname -a
Linux bsrv 4.19.10-tinycore64 #1999 SMP Tue Dec 18 15:18:54 UTC 2018 x86_64 GNU/Linux
[]
$ # did you make sure you're running ndn65 on tcl64?
[]
$ ./ndn
Messagebox():
/mnt/sda2/data/Downloads/-- ndn/ndn_lin/nightly_l64/lib/locale.so: cannot open shared object file: No su

Necromancer's Dos Navigator v3.00.0005f/LINUX64.
Based on Dos Navigator by Ritlabs...
[DEFINES/CPUX64/LINUX/FREEPASCAL]
* Linux (v4.19) detected
* TTY: /dev/tty18 (rxvt)
* Process ID = 7407 ...
* PCRE Version 8.44 2020-02-12
* Berkeley (BSD) socket API for Unix/Linux

When running binaries on wrong platform the binary type gets wrongly identified as shell script by default by the shell itself (since it will accept the fact it is executable). but we both know it is not so... leading to failure of execution.
Thus use the binaries you gave me (ndn64) on a 64bits version of tcl and, unless some libs are missing it should start smoothly.
the way i proceed later if missing libs is :
   ask the bin what is missing :

$ ldd ndn
        statically linked

but since you compile ndn with all its dependencies that should be no worries.

if after that you make it display things nicely and get rid of the locale msg ... that will be huge thank you

JClu

Share this post


Link to post
Share on other sites
Guest JClu   
Guest JClu

OK,
  after conflicting with myself i prefer to include this (should be self explanatory):

 

(i thought the image was insert at text position... well just attached)
JClu, thanks

ndn-202010257-02.png

Share this post


Link to post
Share on other sites
Guest JClu   
Guest JClu

Hi,
 I hope everything is going well for you as the year, sowly but surely, comes to its end.
 It's about time i come reporting some of my experiences, findings, ideas after
 lots of testing on ndn :

1. ascii TUI :
  like with most the TUI based apps, ndn does not display well everywhere.
  Thus, on those *odd* environments, it would be great to get a decently viewable
  interface and, for that purpose, the use of plain ascii characters would be
  a solution (equivalent to the "-a" cli option of mc).
  Extending even further the idea, with a touch of customizability, would be to
  let the user select the set of characters used to display each part of the interface.
  It would be available via menu selector such as the ones for selecting the colors palettes.
  As an illustration one can have a look at the next case (about drawing boxes and lines
  in the editor) with the displaid result and a (possible among others) way to store it
  in a (text) configuration file.

2. lines in the editor :
  just like for the TUI, not every characters displays well on all terminals (depending
  on available fonts|charsets...). So we can imagine a possibility to have alternate sets
  of characters (LS=LineSet, to distinguish from CS=CharSet)to accomplish the same job.
  The LS could even be set related specific CS so that, when switching the display from CS
  to CS, we'd have the lines drawn with the corresponding (predefined) LS for a better user's
  visual experience.
  Here is an example of what could be (visually) expected with CS=ascii.
  Follows an example of possible config file to express the LS for this case (hopefully understandable).
     

            +-------------+            |             |        +----+         +--|-+           |        |    <         |  | |           |        |    |\         |  | |       +-----+      +-+--+ \         |  | |       |   | |       /      \         |  +-|-----------+ |      /      +-o--+         |    |       |     |   +-v--+    |    |         | +==========|==+  |   |    |    |    |         | #  |       |  #  |   |    |    +----+         +----+       |  #  |   +----+           #          |  #  |           #    +==+  +--#--+           #    #  #     #           +====#========+                #  #                +==+        {ascii}          [SL] (H,V,TL,TR,BL,BR)=(-,|,+,+,+,+)          [DL] (H,V,TL,TR,BL,BR)=(=,#,+,+,+,+)          [CL] (C,H,V,OL,OR)=(+,-,|,\,/)          [CA] (L,R,U,D)=(<,>,^,v)        {/ascii}
	      

  I also added an example for connectors, to draw (oriented, because "why not?") lines
  connecting boxes with their corresponding sections CL and CA in the ascii config.

+ This could be too much work to handle and I was only priding the user's perspective on the subject.
  And, as so, seen from the user's POV, this (points 1. and 2.) would increase ndn usability when
  accessed on remote machines and not much time and options are available to adjust all things for
  optimal display.

3. I also met a bug while testing UI and editor :
  as I wanted to copy/paste the entire display into a file via the editor. These are the steps :
    1. 'shift + select-with-mouse' the ndn (or other TUI screen on one terminal (to copy to clipboard) and then
    2. 'shift + Insert' in ndn's editor, open on another terminal (to paste the content of the clipboard).
    3. at that point ndn start doing lots of things, pasting some, switching ndn's windows,... till it, sometimes exits.
         I did not see it display an error but rather behave weirdly.
  my guess is that it was interpreting the pasted content as commands to be executed and not as text to be pasted...
  (a bit the problems i knew in the past between ftp in ascii and in binary...kinda)
  (I know the 'Screen grabber    Shift-Alt-Ins' function (pasting with 'Ctrl-V'), which works... for captures within ndn only)

4. in view/edit : F8 cycles codepage withing DOS, KOI, WIN...  what about addin something UTF8 related?
   making probably the content more portable on modern setups.
   and making it easy to convert between charsets, either within view/edit or from file panels in batchs

5. use case to see difference between screenshots (SS) 'active window' and 'full screen'?
  in my case, setting ndn's terminal as a "floating window" above others in the background
  both type of SS deliver the same file content corresponding to what one would expect from
  SS of 'active window'. In which case are they not the same?
  BTW: files are saved as BMP. Could we have PNG too (or instead) since its more efficient for SS?
  further : casting a movie into GIF/or alt as in https://en.wikipedia.org/wiki/GIF#Animation_formats.

-- the following points are distinct from above and in the category of suggestions|request for added features|evolution
-- so they might seem, from a developper's POV, to go too far but, again, they express how a user (like me) would feel
-- confortable using ndn (all others features kept as they are).

6. Lynx (text web-browser) mode navigation :
  this (ergonomicaly optimal) mode of navigation brings the required finger movements to a minimum in order to
  browse around the FS by only using the 4 direction keys (Left, Right, Up, Down) with :
    Up, Down : behaving the usual way, moving within current dir Up and Down the files;
    Left : goes Up the dir tree (maybe not if the cli is being used)
    Right: gets into a dir if the cursor is currently on one.
           If not we can have customizable possibilities (view file being my prefered -safe- default):
             open|view|edit|... current file
             goto CLI
             contxtual menu
             ....
  and, BTW, such key set has less chances (when well selected) to break on different terminal types (even on remote connections).

7. further on the keyboard/menus/dialogs usage :
  1. getting as close as possible to the association 1key-1action (as opposed to many 3keycombo-1action in the menus):
    if it's the case with many actions initiated with F1-F12 not much for the rest.
    But how? ... there are a few possibilities i think about :
      1. less predifined keys/keycombos so the key space is not alreadu occupied
         and in that case have well thought 1key selectors predifined
      2. give the possibillity to the users to set their own preferred extended key config
         and, again, maybe like for the 'colors palettes' provide a library of such extended configs
         ultimately giving the users the responsability of the setup the most suited to theis specific usage.
      3. another way is the one adopted by vim/emacs : the 'modes'. Users may change ndn current mode via a keycombo
         (a bit like in ndn's editor between text and line drawing).
         Being more explicit :
           for the filemanagers, from the browsing mode :
             1. wether lynx or not way or navigating, you could keep using F1-F12 as usual
             2. when typing text, you's start a quick incremental (regex?) search|filter within current dir
               + by search i mean "bring the cursor to 1st matching item of current dir"
               + by filter i mean "only display matching items of current dir in the current panel"
               + a 1st ESC (or any other predefined 1key) breaks the operation but keeps the panel as is.
               + a 2nd ESC, in the case of filtering, would rediplay all items (not just filtered ones)
               + while in this quick-search|filter mode:
                 + moving up/down would move the cursor within the matching space without leaving search mode so that more letters can be typed to fine tune the search string
                 + Alt+down/up could access a search history/library
                   and now up/down would move within the open search history/library
             3. a predefined (ESC again?) 1key would make the CLI visible (hidden until now) and from now on :
               + moving up/down would move the cursor in the current filemanager's panel without leaving CLI mode so that more letters can be typed to fine tune the command string being input
               + Alt+down/up could access a CLI history/library (a bit like 'Alt+F8' now, just integrated)
                 and now up/down would move within the open CLI history/library
             4. a predefined (certainly not ESC again) 1key switching/cycling between display modes :
               from panels fullscreen (no {menu,Fx-bar, CLI, drives-bar, to user's screen, all bars...
             5. I'm going to speak of 'copy F5' but it will become obvious that i will be refering to the whole set of commands that relaize an certain (set) of operation on (a|selected) file|s :
                0. 'copy F5' opens a dialog box, which is the same as 'rename/move F6' and that is good.
                1. the title of that dialog box would gain in being identical to its calling menu label
                   explicitly 'copy F5' not just 'copy' (maybe customizable) so (new) users can learn their keyboard more easily
                   same for 'rename/move F6' box, and (almost) all the box from 'File menu' (archive, split/comb, ...)
                2. in the 'copy F5' dialog box, when "[ ] Remove source files" is set then the title of the dialog box
                   should follow the change and become 'rename/move F6' and the subsequent dialog/bars sould follow the same 'format'
                   so the users won't have any doubts, in the middle of the operation(s), about what is being done.
                   Actually, going further, most te dialog boxes could be factored into one so users can get more familiar with the common features of the functions :
                     that are all the caracteristics of the copy|move with little specificities: compress|archive (into next panel or new filename), convert/encrypt/hash(create-check...)
                   so, even instead of just "[ ] Remove source files" we could have, eg., a set of tabs/buttons to select from to change the type of dialogbox while in the box.
                   Thus while in copybox, selecting (click of kbd) movetab would change boxtitle AND do "[x] Remove source files"...
                   reversly when in movebox and sel. copyTAB
                   but also copy|movebox then arcTAB...
                   And even further 'make/read file list Alt+L/W' can also join the party here... and i've more to say about them.
           same reasoning for the different other functions of ndn :
             editor/viewer
             calendar/alarms/phonebook...
             ...
           but it's becoming long for a 1st list on this topic alone so better leave for another time, if interested.

     BTW : i distinguished history from libraries in that the history results form past uses of some feature when the library if a custom made list of uses of that feature
           it would be efficient to be editable in-place (and saved) not requiring to add more tools to the set.


8. missing 'extension(|(MIME)type) column' though there is 'sort by extension', which is good/necessary and can even be extended to type instead of extension to fellow mc's idea of using the values returned by linux's "file" command or a regex on the file(name|path).
   further : user defined (set of) columns based on returned values of, eg., some shell script/s.
   eg. :
     media duration (using ffprobe)
     text/docs file stats (wc, antiword, pdftotext, elinks -dump...)
     pix stats (size,nb colors...exif)
     bin/executable (launcher, author...deps ldd)

9. more on columns :
  once set columns width, the remaining panel's with will be used repeating the column set...
  is there a way to not repeat the columns and even to strech|shrink {last|1st|selected} column|s so the set fits the panel width
  mostly needed when changing panel|terminal size...

10. custom functions per file type :
    there would be a default set of options applicable to all files... by default
    and for those typedsthat are configured otherwise, one could see
      + Enter/open using ndn's current oening method or asking for permissions/env.vars/sandboxing or just running some addon launcher app/script... the openers
      + F5/F6 using ndn's copy/move with predefined options or call macros (if available internal language feature for that) or external apps/scripts and passing them files, selections, and other relevant/needed data... the copier/movers
      + similarily with F3/F4 using ndn's view/edit with predefined ... viewers/editors
      + packing/converting... could all be extended the same way ... packers and more (senders like for email, publish web, SMS..., monitors like logs, news..., trackers/killers/ressurectors like servers, jobs...)
    +++ and (users' made) libraries of such extensions could be made available in a repo (like github)
          as an example : 7zip  can handle many archives formats and be used to extend greatly ndn's features without adding to its size.

11. idem for custom VFS : email, web, structured file content, net-protocoles/streams
  which also implies custom columns and content refresh functions

Thank you for keeping with me until here... hope there was anything useful in all i put in here.

I'd be please to see some ofthe ideas implemented as they would improve ndn's usability/siplicity (from a common user's perspective,that is)

JClu

Share this post


Link to post
Share on other sites
Guest JClu   
Guest JClu

... forgot to mentions the reasons why "ext. column" are expected :
  1. visual sorting (separating names & exts
  2. soring by clicking the column's header
  3. editing only exts when modifying file's name
  4. view/hide of the column becomes possible (mostly if remove from the name field) to gain on small screen real-estate
  5. all exts aligned

(and i mean the same for other cols like type, stats & co mentionned in prev. post.

thanks again

JClu

Share this post


Link to post
Share on other sites
Guest JClu   
Guest JClu

any news about the users account?

so i can receive notifications via email and even reply by email...

thanks

JClu

Share this post


Link to post
Share on other sites
Guest
You are commenting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoticons maximum are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×