Inferno OS Android. I have ported as a regular app
bhgv
John Floren
I think you could probably add synthetic files for dialing and SMS as in Hellaphone, probably with a lot less difficulty than we had. That would be fun.
john
Ethan Grammatikidis
helloI have ported Inferno OS to Android (>4.0). unlike the floren one it is a regular native activity (.apk) and may be used in the standard android media with other android apps. (not needs to root)
clasp126...@icebubble.org
> I have ported Inferno OS to Android (>4.0). unlike the floren one it is a
> regular native activity (.apk) and may be used in the standard android
> media with other android apps. (not needs to root)
>
> https://github.com/bhgv/Inferno-OS_Android
can run Inferno). You are my hero! Where do I send donations? (Can
you receive Bitcoin?)
Those of you who've tried this (or are planning to) will probably have
one or two burning questions:
(1) Where is the backspace key? One doesn't appear on the keyboard,
but you can achieve the same effect by pressing the button for
Control and then "h".
(2) Why do I just get a big, black background and nothing else? That's
probably because the Inferno app can't find the Inferno file tree.
The Inferno/ tree needs to be unpacked under /sdcard/, which
(counterintuitively) represents the INTERNAL storage in the device,
NOT the "SD Card" that you've plugged into it (which gets mounted
elsewhere).
clasp126...@icebubble.org
> Those of you who've tried this (or are planning to) will probably have
> one or two burning questions:
value of $running). Now, I'm trying to configure it to the point of
being a fully-usable Inferno installation.
When I run hosted Inferno, I generally pass command line arguments to
emu in order to set up the name space (with things like /home and /tmp
from the host OS) prior to invoking wm/wm. But the Inferno-OS_Android
app (aemu) is invoked by selecting an icon, not by issuing a command at
a prompt, so I can't find any place to specify such initialization
commands.
I thought about using newns(2) or /lib/wmsetup to setup the namespace
the way I want, but newns(2) is only called by logon(1), which requires
the user to already have a home directory under /usr. And /lib/wmsetup
will only run $home/lib/wmsetup (if it exists), where $home is defined
as home=/usr/^"{cat /dev/user}. So, whether going through logon(1)'s
newns(2) or directly to toolbar(1)'s /lib/wmsetup, the user's home
directory needs to be mounted under /usr before invoking wm/awm.
Is there a way to pass configuration commands to wm/awm, like those
accepted by wm/wm?
(For clarity, I more or less consider an Inferno install to be
fully-functional when Acme is up and running and usable. I haven't
quite gotten there, yet.)
Ethan Grammatikidis
> clasp126...@icebubble.org writes:
>
> > Those of you who've tried this (or are planning to) will probably have
> > one or two burning questions:
>
> So, I've gotten Inferno-OS_Android $running easily enough (for some
> value of $running). Now, I'm trying to configure it to the point of
> being a fully-usable Inferno installation.
>
> When I run hosted Inferno, I generally pass command line arguments to
> emu in order to set up the name space (with things like /home and /tmp
> from the host OS) prior to invoking wm/wm. But the Inferno-OS_Android
> app (aemu) is invoked by selecting an icon, not by issuing a command at
> a prompt, so I can't find any place to specify such initialization
> commands.
>
> I thought about using newns(2) or /lib/wmsetup to setup the namespace
> the way I want, but newns(2) is only called by logon(1), which requires
> the user to already have a home directory under /usr. And /lib/wmsetup
> will only run $home/lib/wmsetup (if it exists), where $home is defined
> as home=/usr/^"{cat /dev/user}. So, whether going through logon(1)'s
> newns(2) or directly to toolbar(1)'s /lib/wmsetup, the user's home
> directory needs to be mounted under /usr before invoking wm/awm.
Ethan Grammatikidis
how to install/try (only arm yet)========================1. go to [project's github home](https://github.com/bhgv/Inferno-OS_Android),2. go to releases download section,3. download were `inferno-os.apk` and `inferno-filetree.zip`4. unzip `inferno-filetree.zip` to android's sdcard root. it should be `/sdcard/Inferno`5. install `inferno-os.apk` and run it
bhgv
(i remember, you did this by sending AT commands to /dev/tty of the modem. now also this may be done. directly from limbo, but it will require root)
bhgv
I do not know how to use bitcoins. and do not really trust them.
суббота, 3 февраля 2018 г., 22:49:49 UTC+2 пользователь clasp126...@icebubble.org написал:
bhgv
воскресенье, 4 февраля 2018 г., 7:06:46 UTC+2 пользователь clasp126...@icebubble.org написал:
bhgv
BUT, it's a bit incomplete. It should be slightly polished to modern requirements. first of all GUI. it got stuck in the 90s. special formats for pictures and fonts.. you can not explain to designers how to make .bit files in Photoshop/Corel/GIMP. you can not offer an application to a customer with such GUI. it's like cars - a bad but beautiful machine will interest users more than good but ugly.
воскресенье, 4 февраля 2018 г., 15:31:35 UTC+2 пользователь Ethan Grammatikidis написал:
bhgv
@Ethan Grammatikidis |
when Android starts another application it can partially unload the previous one, free its resources, memory. perhaps this is what was happening in your case. look in the log. if the cause of the error is access to invalid memory - this is it.
Ethan Grammatikidis
> @Ethan Grammatikidis
>
> > I see one bug in this early test, but it's not terrible: taps toward the bottom of the screen are offset downward and a little to one side. Using the keyboard as an example, at the top of the screen i can tap on a button to activate that button, but at the bottom of the screen I have to tap on <- to get Shift, ` to get Enter, and the close button to get <-. I think I can live with it.
> please show me a screenshot. inferno's internal keyboard works well for me, except of very small buttons. but the problem here is bigger. Inferno has only fonts of small sizes. and keyboard should be rewritten to autosize itself. because of different and high resolutions of devices.
> !!
> > I will have to increase the font sizes for (almost) everything, but I've done that before.
> may you describe this? how to make sizes of fonts bigger? do you make bigger 'size' and and 'accent' fields in .font files or use a special tool? or you know internal format of subfonts (i read mans. they are not too detailed)? or maybe you worked with fonts inside `libdraw`?
>
> fonts are big problem of inferno's GUI. maybe you know any tool to do/convert new fonts (subfonts)? or to see their internal structure in details?
> i know, they are long strip of bitmaps of characters of the sufont in the internal Image format. after header with the details of whole subfont (number of characters, height etc). after is a list of details of every character in the subfont. BUT. there is a detail or details that i don't know. any source of tool that can do this subfonts may help.
> !!
https://9fans.github.io/plan9port/
https://9fans.github.io/plan9port/man/man4/fontsrv.html
The man page is out of date, I used it to get fonts from a Linux/X11 system a year or more ago.
To get Inferno to use my fonts everywhere, I removed the fonts and subfonts it normally uses, and made new font files with the same names as the old, but with relative paths to subfonts of the fonts I wanted to use. Of course, the height and all must be the same as the font to use. It took a little bit of work, but the end result was very nice for everything except the output of mc in the shell. I would attach examples and a script, but my old files are hard to access at present.
> > It's certainly better than a certain other programming environment for Android
> I think that inferno is potentially the best programming environment/framework of the existing ones. it is lightweight, fast, opensource, ported to many platforms and easily portable, has 2 not very complicated programming languages, streams, strong network support, excellent internal structure, GUI, built-in powerful graphical debugger, expandability/extendability and many more.
> BUT, it's a bit incomplete. It should be slightly polished to modern requirements. first of all GUI. it got stuck in the 90s. special formats for pictures and fonts.. you can not explain to designers how to make .bit files in Photoshop/Corel/GIMP. you can not offer an application to a customer with such GUI. it's like cars - a bad but beautiful machine will interest users more than good but ugly.
I like your window buttons, but not with the old blue title bars! :) I hated the Windows 95 look in the 90s, but I don't care too much about uglyness any more. I intend to do my own graphics work anyway. I care about lack of scaling a little more, but it does not kill me.
Funnily enough, the "certain other programming environment" I complained of has a 90s look too. What upset me was that the guy who made its window system made it for Android, but didn't think about the requirements of touchscreens at all. Inferno on the other hand has an adequate window system for small touchscreens, with a button to resize it, developed in the 90s.
bhgv
* added support of command line.
/lib/startup/cmd_line.txt
should be single line. in format of regular emu call without the word 'emu'. command line has restriction: no any console, graphic params (size, channels) not used because they depend to device.
* added experimental support of .ttf fonts (thanks to Ethan Grammatikidis for example). to use:
create a standard font file. ex: 'test.font',
in places of subfonts write your ttf fonts,
use this font file
thats all
currently only chars from (0-255) and 18 size are available. but this only for testing
sources and apk are on the github
bhgv
Inferno receives coordinates of taps/moves direcly from Android ndk without any conversion. i tryed on a couple of my phones/tablets and their taches worked correctly. i think your problem should be debugged deeper.
thanks to your example of building inferno-fonts with freetype i added support of `.ttf` fonts (and maybe other?) to use them by Inferno directly as a regular inferno-subfonts.
about tools to convert image formats in the inferno, i've added readers of png and svg. laiter may add readers of jpg and other. maybe writers to png and others too. it's a time.
w95-style headers are horrible. but! i'm not an artist. completelly. many of inferno-tk controls are skinnable ('-bitmap' key). but someone should besign its look first. for ex i like the look of my xubuntu, but can't to design something like it.
the source of windows' captions is in `/appl/alib/titlebar.b`
clasp126...@icebubble.org
> I think you could probably add synthetic files for dialing and SMS as in
> Hellaphone, probably with a lot less difficulty than we had. That would be
> fun.
to all the basic hardware. Access to the accelerometer would be nice,
too, but not really necessary. GPS could be accessed over TCP using
apps like BlueNMEA (http://max.kellermann.name/projects/blue-nmea/),
which emulates a GPS receiver by synthesizing a stream of NMEA data and
serving it on a TCP port.
Come to think of it, we could add hardware support to this port (Inferno
OS Android) by writing Styx servers for each piece of hardware as native
Android apps. So, for example, a "Styx SMS App" could provide access to
the Android SMS services over 9P, making SMS immediately available to
applications running under Inferno.
This could be done for each piece of hardware, saving the effort of
having to build support for each device into emu. As an added bonus,
you'd be able to remotely access a device's hardware (say, its speaker)
without needing a full installation of Inferno on it. The drawback to
this approach, however, would be the need to install a separate Styx
server App for each piece of hardware (if it's not implemented in emu).
clasp126...@icebubble.org
> * Touch screen. Only single touches. Don't know where to use
> multitouches in the Inferno,
bhgv <bhgv....@gmail.com> writes:
> but Acme?? how do you propose to emulate 3 mouse buttons on phone's
> touchscreens? what do you propose to do with very small Acme buttons (or
> itself. because of different and high resolutions of devices.
configured with a button to resize the window. That way, the user could
resize/move it and at least reach all the keys (even if a bit
inconveniently). Adding the resize button to the title bar wouldn't
take up any additional screen space.
The on-screen keyboard is one place which could use multitouch. One
could, for example, hold down the Ctrl key while typing "C" to generate
^C, just like on a hardware keyboard. Shift+"4" gets you "$", etc.
(How many touches can multitouch give you? Could you press Shift +Ctrl
+Alt +X, using four fingers, for example?)
Mode shifts like that (either by adding two more buttons to the
keyboard, or using a separate GUI) could also be used to emulate mouse
buttons 2 and 3, just like Mac OS users emulate middle/right clicks by
holding down keys while using a one-button mouse.
Mouse buttons 2 & 3 could also be emulated using the Volume Up/Down
buttons. These are used by the Android terminal emulator app, for
example, to enter control characters, arrow keys, and the like using the
on-screen keyboard.
bhgv
пятница, 2 февраля 2018 г., 4:21:55 UTC+2 пользователь bhgv написал:
bhgv
> to all the basic hardware. Access to the accelerometer would be nice,
> too, but not really necessary.
> configured with a button to resize the window
вторник, 6 февраля 2018 г., 3:51:07 UTC+2 пользователь clasp126...@icebubble.org написал:
bhgv
пятница, 2 февраля 2018 г., 4:21:55 UTC+2 пользователь bhgv написал:
hello
bhgv
clasp126...@icebubble.org
> * added support of command line.
>
> /lib/startup/cmd_line.txt
>
> should be single line. in format of regular emu call without the word 'emu'. command line has restriction: no any console, graphic params (size, channels) not used because they depend to device.
an .rc file in a file named something like $home/.inferno_env (on the
host Android FS for the user running the App)? The file could contain a
sequence of var="val" pairs to be added to the environment before
invoking emu. By setting emuargs="...", arbitrary arguments could be
passed to emu. In addition, any other desired environment variables
could be passed to the Inferno environment using the same mechanism.
It's not even necessary to be able to edit the .rc file from within
Android. The first time a user starts Inferno via the App, they see
that some configuration is necessary, so they mount '#U', run brutus on
~/.inferno_env, restart emu, and voila! Everything's initialized the
way they want. This mechanism could even be used to override setting
like "-r" and "-g" if desired.
clasp126...@icebubble.org
> access from NDK to sound system, camera accelerometer are well described in
> the NDK examples. code may be taken from there.
> phone and SMS - i don't know. my memory tells me they require to use JNI.
>> on-screen keyboard is one place which could use multitouch ... etc
>
> multitouch has one more problem - Inferno's pointer device don't support
> it. to support multitouch (ctrl+alt+shift+'key') devpoiter should be
> rewritten. + should be rewritten `keyboard.b`. this is a little a lot of
> work.
able to solve this problem in the time domain:
press(10,20)
press(100,100)
release(100,100)
release(10,20)
...would indicate that a button at (10,20) is being "held down" while a
key at (100,100) is being "pressed". You just watch for multiple
mouse-down events without an intervening mouse-up event. At least for
the on-screen keyboard, that should be "multitouch enough" to enable key
chording.
> very small widgets. I have to use an awl)
bhgv
========
first it should be mapped to `/dev` fs:
```
bind -b '#A' /dev
```
possibilities:
-------------
* reading of `/dev/audio` will reads the phone's mic (44.1kHz, 16bit, stereo, raw wave without headers and compression). ex:
```
cat /dev/audio > snd.raw
```
* writing to `/dev/audio` will outputs the data was written to phones speaker (44.1kHz, 16bit, stereo, raw wave without headers and compression). ex:
```
cat snd.raw > /dev/audio
```
* `/dev/audioctl` supports now next commands (only writing to):
* * `load file <file path in the inferno's fs>` - loads the specified file, but don't start to play,
* * `load uri <uri address of a stream to play>` - loads the specified network stream, but don't start to play,
* * `unload file` - unloads last loaded file and free used resources,
* * `unload uri` - unloads last loaded network stream and free used resources,
* * `play file` - play the loaded file,
* * `play uri` - play the loaded uri,
* * `stop file` - stop playing of the file,
* * `stop uri` - stop playing of the network's stream,
* * `loop file` or `loop uri` - loops playing of the file or the stream.
all sound streams: record, output of raw wave (`/dev/audio`), playing of a file and network stream use separate buffers and may work simultaneously.
ex:
```
echo load file /mp3/a_music.mp3 > /dev/audioctl
echo play file > /dev/audioctl
```
or
```
echo load uri http://ice1.somafm.com/dubstep-128-mp3 > /dev/audioctl
echo play uri > /dev/audioctl
```
(thanks to somafm.com network radio for provided demo net stream)
2nd and 3rd mouse buttons
======================
2nd and 3rd mouse buttons are emulated using multitouch possibilities.
how to do
----------
point or select what you need with 1 finger, after tap somewhere with 1 or 2 more fingers. this will couse a click of 2nd or 3rd mouse button.
coordinates of the click is the coordinates of the first finger.
copy/snarf - paste
===============
copy-paste functionality is working now. but only with texts yet.
Inferno's copy paste buffer is separated from the Android copy-paste buffer. actually no way to copy-paste between Inferno and Android.
PNG image's resizing
=================
Tk now is able to resize `.png` images on load - `-bitmap :<new-max-size-in-points>:<png-path>.png`
Autoscaling of windows' captions and main toolbar
=========================================
* main toolbar now autoscales to 1/20 of Inferno's activity height,
* windows' captions autoscale to 1/30 of activity height,
* lines in the main menu - to 1/30 of activity height.
including of their icons/buttons
to recieve of autoscaling dis files should be recompiled and replaced with new ones. or to wait a new inferno-filetree.zip
--------
command line is loaded, parsed and utilised by inferno BEFORE any other settings. that time inferno don't know the user name, path and other.
inside inferno has a parser of command line only of this format and these parameters. actually i have very little time to program this Inferno's port as i should to work for money too, not only for free. and inside Inferno are many more important things to porting except the command line. i hope we understand each other.
---
NDK == Native Development Kit.
- gcc + llvm + libraries + heders for Android. the main toolchain from Google for C/C++ development for Android.
JNI = Java to Native Interface.
- the main interface to communicate between C/C++ and Java layers.
google, plese. your email name requires the best knowleges in the programming. called a mushroom, gets into the box.
bhgv
Joel Fridolin Meyer
checked issue with widths of some letters (ex: space) in the ttf fonts. now they are displayed normally.
bhgv
ex:
```
font : ref Font;
# font = Font.build(<name of this font>, "<height of the font> <accent of the font>\n0x0000 0x7fff <name of ttf font used as subfont>\n");
font = Font.build("vera_new_17, "17 14\n0x0000 0x7fff /fonts/ttf/Vera.ttf\n");
```
after this you may use *font* or name of this just built font in your Tk controls and for other operations.
**Note:**
names of fonts SHOULD be different! because Inferno caches fonts and searches of them by their names!
* command line now supports `.ttf` fonts directly as the default Tk font (`-f`). in this case the font will be autoscaled before the install in the inferno system.
* titlebar, main toolbar (including the main menu), keyboard an man (help viewer. 'Noto' fonts from Ubuntu) now used with autoscaled fonts. they look better on any resolution and they (`/appl/awm`) may be used on desktops too instead of not autoscaled `/appl/wm`.
@sirjofri
thanks for your feedback
@All
if anyone wants to support of development of this port of Inferno (or fork? it (inferno-os folder) may be compiled and used also with different OSes. for example i debug it on windows with the regular msvs debugger (it is better then ddd)),
he may donate me.
with your donations i may do more and better as i may work on Inferno more time.
really, supporting and investing to Inferno OS development and me is better and profitable as supporting and investing to budweiser and john mc cain.
a beer costs nothing it may be made by everyone. development of Inferno OS is a hard work and this may be done only by suitably qualified people.
bhgv
now Inferno after an internal error writes to the `/sdcard/Inferno/calltrace.log` file desription of the error and the list of calls of functions before this error appeared.
ex: if Inferno freezed or breaks - send me this calltrace.log
but this is a first step, an experiment yet.
(new testing apk is in the releases download section as usual. or to build it by yourself. no updates in .dis files)
bhgv
devgui (`#G`)
--------------
a try to do more easier and convenient way to work with Inferno's Tk.
as a bonus Tk widgets trees/info may be be explored remotelly using Styx.
now it shows Tk widgets hierarchical trees sorted by pid.
every widget's name is in the form `<id-of-the-wiget>.<tk-type-of-the-widget>`.
every container widget (a widget with slaves) looks as a folder. inside such folder is a file `.self` to control container-widget's options.
to get the list of widget's options just read the wiget's file (or `.self`). this list is not fully complete yet. only the configure/cget options.
ex:
```
bind '#G' /gui
cd /gui
ls # to see the list of all progs in the Inferno by their pids
cd 10 # 10 is a pid of shell in my case.
ls # to see toplevel widgets.
cd cons.* # last part of the widget's name is its type. write '*' insted it.
ls -l # to see slaves of the 'cons'. '-l' gives more info.
cat scroll.*
cat t.* # reading from widget's files gives the list of its options not complete yet. only configure/cget ones
```
for more convenient using add a string to `/lib/awmsetup`:
```
bind '#G' /gui
```
to get the pid of the current app just use:
* `Sys->pctl` from the limbo's source.
* or `${pid}` in the shell command/script (but it gives the pid of the current shell thread)
ex:
```
cd /gui/${pid}
```
-------------
donate me and the work on Inferno-OS. just a couple of bottles of beer from you (by paypal) will significantly improve the condition and expand the possibilities of Inferno-OS!
maybe someone else will do this and do this faster and better? but this is perhaps 'maybe' and perhaps 'faster or better'.
but you are able to do this just now and just with a couple of bottles of beer from you!
bhgv
======
* a possibility to write to widget's files commands (like Tk ones, but without the name of the widget) and if it's necessary to read the result of just (before closing of the file) sent command.
ex ('Log' window):
```
cd /gui/10
echo configure -bd 25 > .self # will do borders of the Log window wider
cd c* # or /gui/10/c* - go to Log window's console
<> t.* {echo get 1.0 end >[1=0]; read} # get the text from the console's text widget
```
* output of widget's files was changed to be compatible with their input (and changed a little Tk itself as it doesn't have some functions. for example it doesn't have a possibility to know the name of the picture was loaded by '-bitmap' command).
now using reading/writing from/to a widget's file it's possible to store/restore/clone of widget's options.
ex:
```
cd /gui/10/c*
echo insert end '''' A text > t.* # '''' is need to do single ' in the sh
cat t.* > /buf # store
cat /buf > t.* # restore
cat t.* > t.* clone (clone to iself here, but it may cloned to other widget with same type
```
### note:
commands are executed (while they are wited to widget's file) line-by-line. BUT if you need to send a multiline command (for example set a multiline text) close this command with quotes. ex:
1. insert end 'a single line case 1
1. "insert end 'a single line case 2"
1. "insert end 'a multiline
line 2
line 3
etc
"
### inferno-os tree itself
inferno-os tree may be build on Windows and Linux (not tested very well) separately from the Android wrapper. actually i debug it as a regular Windows app separately from Android wrapper. (maybe will move it to other git)
### donations:
they are necessery to long live and development of the Inferno OS and this fork. programming inside the inferno's kernel is a big work because there is no any info/help and other on its structure/functions and technics.
all info may only be obtained by careful examination of the source and experiments. it takes a lot of time and requires a lot of effort.
(I think this is the main reason of such slow development and not a big popularity - the difficulty to develop, change for their own purposes)
in addition, the code contains errors and inperfections (not too much, but they are). for example, in the basic Inferno, each Tk widget creates its own copy of its font(s) without checking the cache of fonts created earlier (i fixed it). there's no way to know the name of the image loaded into the widget with the '-bitmap' command (fixed it). etc
Ethan Grammatikidis
>
> ### donations:
>
> they are necessery to long live and development of the Inferno OS and
> this fork. programming inside the inferno's kernel is a big work because
> there is no any info/help and other on its structure/functions and
> technics.
i say this because i am sorry, i would like to donate, but, after consideration, i have no desire to use inferno any more, and so i feel i can't justify paying for it. i started to learn limbo earlier this year, and found it a drag. instead, i got into forth, and i'm thoroughly enjoying it! it's early days yet, so that could change, but i don't think it will. instead of restrictions and a set array of features, keep your "word definitions" small and test them thoroughly. the interactive environment for testing, (which even compiled forths have,) is fun; the kind of fun i haven't had since i upgraded from an 8-bit computer. i can only really think of one sort-of similar thing which came from lab 1127: inferno's shell, but i found that too arcane. i know bits and bytes and memory addressing, i don't know this "higher-level" stuff which is just as complicated in its way. in fact, can you use any limbo module from inferno's shell, without changing the module? if not, it's not the same at all. i've got more arguments, but i don't really want to be discouraging. maybe some day i'll write a forth interpreter for the dis vm. :)
>
> all info may only be obtained by careful examination of the source and
> experiments. it takes a lot of time and requires a lot of effort.
>
> (I think this is the main reason of such slow development and not a big
> popularity - the difficulty to develop, change for their own purposes)
>
> in addition, the code contains errors and inperfections (not too much,
> but they are). for example, in the basic Inferno, each Tk widget creates
> its own copy of its font(s) without checking the cache of fonts created
> earlier (i fixed it). there's no way to know the name of the image
> loaded into the widget with the '-bitmap' command (fixed it). etc
bhgv
files/folders for widgets should have names of special form: `name_pt.type_pt`.
* `name_pt` should not contain any points (`"."`) or spaces (`" "`). `name_pt` should be unical in the its folder. this will be used as an **Id** of this widget.
* `type_pt` is a type of created widget. it's may be:
* * frame
* * label
* * checkbox
* * button
* * menubutton
* * menu
* * separator
* * cascade
* * listbox
* * scrollbar
* * text
* * canvas
* * entry
* * radiobutton
* * scale
* * panel
* * choicebutton
ex:
```
cd /gui/10/W*
echo 'configure -text HelloWorld!' > tst.button
# open the Log window to see the result (in the Log's caption)
rm tst.*
# see to the Log's caption again
```
these possibilities may be used to:
* fast storing/restoring/sending/cloning full or part of the gui system of the app,
* using of styles. just prepare files like *css* but in the Tk style and write them to the widget file,
* designing of the gui. just design somewhere a tree of text files with styles and correct names and copy/remove of them to gui filetree,
* use of Inferno Tk gui from your own language. not Limbo or Sh (not complete yet. you still should create tktop from limbo or sh)
// apk for testing in the releases download as usual
@Ethan Grammatikidis
thank you for your responce
inferno is not only limbo or sh. biggest part of Inferno is written on a regular C. it use 2 common types of interfaces: as Styx device and as a Limbo module. they both not too complex to understandment and using.
you want to program in Fort? it is no need to build it on Dis vm. build it on its own vm. all that you need - C based interpreter the code of it you are understanding and possible to modify.
because you should change 'main' function to the form of the limbo's internal module's interface (it's easie than a Styx device)
there to get C-based forth interpreter? may be here
https://github.com/howerj/libforth
(i searched 5 minutes. maybe you know better)
and you should build the forth interp chousen by you test how it compile and how it works before the start of embedding.
when you will be ready - ask me and i will describe you how to write interfaces of internal limbo's modules. and you may use all inferno's possibilities including Styx, network and tk directly from the Forth.
as for me, i planned to embed lua in the future as a middle level language. it is small, fast, highly portable, has a very simple but powerful syntax.
Inferno isn't only limbo vm and it's not an OS. it's a very good and powerful crossplatform framework/platform. and it is C-based.
(look: Android OS == Linux kernel + Java framework => Android OS - Linux kernel == Java framework)
and you may develop with Inferno on most of OSes without any additional porting, any slow virtual machines, any complex build system (Android) and so on.
only one thing is bad in the Inferno. its external look from the middle of 90s. i can't to draw, but this should be repired.
about non-technical work. i tryed this. i tryed many works. it doesn't work for me.
i get tired, distracted. for programming you have to look inside yourself. a case of meditation. for normal work - on the contrary. the switching time goes away. as a result - i manage to do less.
besides, i lose experience. doing normal work i also get experience. changing the work, i stop receiving it. and the old experience begins to be replaced by the experience of the new work.
also, it's less money. since i do not have experience in a new job, then i must start with 0. with a courier or volunteer salary.
i personally share time for myself. and by day and by hour. in different parts i do different things. just make notes on the border of the part to go back and forget the previous one (you need a little training in this)
also, very good results give trips. without changing the specialty. live in another city or another country. only in europe there are a lot of different places with very different traditions.
the programmer does not have enough fresh emotions. emotions are a fuel for creativity. therefore, programmers or designers spend them in an increased amount. they must be received.
but if you change your job, you will refuse both salary and experience.
remembered more. to less tired to do sometimes a week without coffee. you can drink tea. and at least once a week sleep well.
---
limbo modules are like java modules or python midules, or windows/linux dll/so (closer to com-objects) but smaller. executable from sh or wm or just a lib have differences only in the format of the 'init' function. but since the 'init' function is called manually, it may not be present at all.
ohh, a lot of letters..
the most important part:
-------------------------
@All
your donations are very important. your investments in Inferno will allow it to grow, realize its potential and your dreams and expectations.
you can write 1 program at once for all existing platforms, easily create local, cloud and distributed applications. realize even the most fantastic expectations about IoT and thick clients.
you will be able to translate your ideas, and not just to study and again study yet another complex technology that is almost identical to the previous ones in terms of capabilities!
djr1...@gmail.com
you sir are a prince
djr1...@gmail.com
cant believe
Ethan Grammatikidis
>
> @Ethan Grammatikidis
> thank you for your responce
> inferno is not only limbo or sh. biggest part of Inferno is written on a
> regular C. it use 2 common types of interfaces: as Styx device and as a
> Limbo module. they both not too complex to understandment and using.
>
> you want to program in Fort? it is no need to build it on Dis vm. build
> it on its own vm. all that you need - C based interpreter the code of it
> you are understanding and possible to modify.
>
> because you should change 'main' function to the form of the limbo's
> internal module's interface (it's easie than a Styx device)
it seems obvious now you mention it! the only question is, would i
want to? having considered carefully, i think it's amongst my best
options. another is gforth, which will run on systems inferno just
isn't maintained for. like many forths, gforth can use any c library
without recompilation. on the other hand, gforth doesn't have a
window system, it would be nice to keep styx/9p around, /dev/draw
is familiar, and /dev/snarf is a great tool.
> there to get C-based forth interpreter? may be here
>
> https://github.com/howerj/libforth
>
> (i searched 5 minutes. maybe you know better)
more than one in the long run. it's a sort of rite of passage in the forth world.
> and you should build the forth interp chousen by you test how it compile
> and how it works before the start of embedding.
> when you will be ready - ask me and i will describe you how to write
> interfaces of internal limbo's modules. and you may use all inferno's
> possibilities including Styx, network and tk directly from the Forth.
>
> as for me, i planned to embed lua in the future as a middle level
> language. it is small, fast, highly portable, has a very simple but
> powerful syntax.
>
> Inferno isn't only limbo vm and it's not an OS. it's a very good and
> powerful crossplatform framework/platform. and it is C-based.
> (look: Android OS == Linux kernel + Java framework => Android OS - Linux
> kernel == Java framework)
because it provides a complete environment of consistent design.
still, it's just a matter of definition. i don't think there's a clear line
separating frameworks from operating systems.
>
> and you may develop with Inferno on most of OSes without any additional
> porting, any slow virtual machines, any complex build system (Android)
> and so on.
those OSs involves complex build systems and piece-by-piece porting
as the operating systems change. still, if i want to reach all my ambitions,
i will have to involve myself with something like this in the end.
>
> only one thing is bad in the Inferno. its external look from the middle
> of 90s. i can't to draw, but this should be repired.
the trouble is, if i do it, it'll look like it was designed in the 80s, or maybe a
kids' cartoon! :) still, windows 10 looks a lot like the fvwm setup i made
8-10 years ago, so maybe my styles are back in fashion. if i make graphics,
i'll try to let you have them.
small suggestion: making tk's vector graphics
anti-aliased would help bring them out of the 90s. i wanted to offer a
library suggestion, "anti-grain geometry", but i see now it's c++ and would
thus hinder compiling for native. i mention agg because another
tk-on-android system uses it and it looks nice.
http://www.antigrain.com
i'm not saying who the other tk-on-android people are because, when i
reported as a bug the impossibility of manipulating 1- or 2-pixel-wide
borders on my tablet, let alone my phone, they told me it's a hardware
fault. i'll have you know i have very delicate fingers! (LOL) inferno has a
more practical touchscreen interface, and it's almost a quarter-century
old. i *hope* they misunderstood my bug report, but i didn't follow it
up for various reasons.
>
> about non-technical work. i tryed this. i tryed many works. it doesn't
> work for me.
> i get tired, distracted. for programming you have to look inside
> yourself. a case of meditation. for normal work - on the contrary. the
> switching time goes away. as a result - i manage to do less.
could see what i was working with, but for programming i had to learn to
stop, rest, and meditate.
>
> besides, i lose experience. doing normal work i also get experience.
> changing the work, i stop receiving it. and the old experience begins to
> be replaced by the experience of the new work.
>
> also, it's less money. since i do not have experience in a new job, then
> i must start with 0. with a courier or volunteer salary.
>
> i personally share time for myself. and by day and by hour. in different
> parts i do different things. just make notes on the border of the part
> to go back and forget the previous one (you need a little training in
> this)
practice to not write too much or go off on tangents, but it's working pretty
well now. sometimes i need to delete or move some of the notes.
>
> also, very good results give trips. without changing the specialty. live
> in another city or another country. only in europe there are a lot of
> different places with very different traditions.
>
> the programmer does not have enough fresh emotions. emotions are a fuel
> for creativity. therefore, programmers or designers spend them in an
> increased amount. they must be received.
wanted to program or make other art, i could sometimes do a little but then
i was stuck, "artist's block". reading books sometimes helped with the art.
>
> but if you change your job, you will refuse both salary and experience.
>
> remembered more. to less tired to do sometimes a week without coffee.
> you can drink tea. and at least once a week sleep well.
tired the next day.
>
> ---
> limbo modules are like java modules or python midules, or windows/linux
> dll/so (closer to com-objects) but smaller. executable from sh or wm or
> just a lib have differences only in the format of the 'init' function.
> but since the 'init' function is called manually, it may not be present
> at all.
> differences only in the format of the 'init' function.
wrapper in limbo? it may not be a difficult task at all, but it's another task
to do, and more files to create, before my 20-line script can run.
for years i've been frustrated by exactly this sort of thing in plan 9 (which
has the same authors as inferno). it's true i was held back by spending my
creative energies on other things, but not all the time.
in forth, the same language can both load libraries, *any* libraries, and for
example be the command language for a text editor. the libraries don't have
to be prepared for forth *at all*. a very short script could access any public
symbol in any library, the only potential obstacle being a non-standard
calling convention! a forth user once wrote that, for work, he wrote libraries
in c++ for linking with c++ programs, but he tested them in forth because
it was quicker and easier.
i suppose ken thompson, dennis ritchie, and the rest wanted to provide
interfaces both safe and simple. i can understand that. in forth, i've had
bunches of stack underflows and at least one each stack overflow and out
of bounds access in less than a week. forth isn't as simple as the shell or
file interfaces. i will personally be sticking with forth because none of the
errors were a problem for long, forth is simpler than limbo, and it's easier to
test anything than in any non-interactive language.
>
> ohh, a lot of letters..
>
>
> the most important part:
> -------------------------
> @All
>
> your donations are very important. your investments in Inferno will
> allow it to grow, realize its potential and your dreams and
> expectations.
>
> you can write 1 program at once for all existing platforms, easily
> create local, cloud and distributed applications. realize even the most
> fantastic expectations about IoT and thick clients.
>
> you will be able to translate your ideas, and not just to study and
> again study yet another complex technology that is almost identical to
> the previous ones in terms of capabilities!
almost everything i've heard from them says YES, the model of presenting
devices and services as filesystems and exporting filesystems (which plan 9
shares with inferno), is very good and much easier to use than any other
network interfaces.
the two (two!) exceptions concern performance under certain circumstances,
and the expectation that the network is reliable. concerning reliability,
bhgv, you may wish to look at aan in 9front. it's a simple protocol intended to
provide persistence for 9p connections where one end may disconnect or
change ip address.
the performance problem may have come and gone as the internet has
changed. last year, a guy living in berlin with a server in france was very happy
with the performance of remotely mounted draw devices which, as you can
imagine, are rather demanding.
if it is a problem in any way now, there are several options. it's a round-trip
latency problem, so one option is changing programs to issue requests in
parallel. this is done by the fcp command in inferno -- cp(1). i think it's not
been done because it would require adding the complexity of latency
awareness to every program. (even fcp isn't really 'aware', it just has an option.)
another is to add streaming extensions to 9p. there have been various
suggestions in this area. the only name i remember is πp (pi-p). πp was not
well-received, but recently cinap_lenrek (9front developer, author of aan and
many other things,) has been wanting to add streaming extensions too.
i mention him because he's a skilled developer, and it'll be good if it's
developed for both plan 9 and inferno at the same time.
then there's octopus, based on inferno, which has an additional file protocol,
Op, with weaker semantics than 9p but automatically better performance over
high-latency links. i'm afraid the best link i've got to that is a web search:
https://duckduckgo.com/?q=inferno+octopus+operating+system
this paper is quite short, and fascinating:
https://lsub.org/export/otut.pdf
information on it does seem to be scattered. octopus development was focused
on sharing resources (e.g. sound) between computers. i imagine that could be a
'killer app' on phones and tablets, if complexity hasn't risen too much in the
interim. it also had a different window system.
hiro
hiro
personally is that cinap added aan also to the 9front drawterm fork,
and dp9ik of course :)
it's a very simple concept that strangely got left ignored in the
source tree for a long time. but now i use it every day.
bhgv
@Ethan
to make a library module, just make a sh or wm module, debug it (inferno has a good graphical debugger. compile with -g key to produce debug symbols). then it will be ready just separate iterface part to .m file and change 'init' function.
about your forth interpreter
----------------------------
(a years ago i programmed on ps. a kind of forth for documents. ps, eps, pdf). i think this is a good idea. to get access to different inferno-possibilities you should only add file functions.
stack := "" :: ""; # init stack
stack = "new-member" :: stack; # push to stack
top_member = hd stack; stack = tl stack; # pop from stack.
also you need two hashtables of stacks (function is a long chunk of stack, a regular variable - short one)
easy way to calculate short hashes in the inferno i will write a little later if you want.
about the AGG.
--------------
i used AGG some time ago. agg does the best quality graphics. BUT, internally it is fully based on templates, not only C++. this makes it hard to port and debug. after, i used cairo. a little less excellent quality, but much easier in work with it.
streaming extensions to 9p
---------------------------
hmm, that do you mean? like an internet radio?
you may do this on the regular 9p/styx. without any extensions.
for example, all graphical operations go to/from devdraw. then you open a window - it opens devdraw files, then you close the window - it closes opened devdraw files. this frees all the associated with this window resources.
file in the inferno is not a just file with size. it is a named channel. do with it what you want.
about octopus
--------------
idea about gui as filetree was taken from octopus.
but about its protocol, i don't know. 9p is not so bad.
and it has some possibilities almost unused, but used, for example, in qnx. for dynamic loading, unloading and overloading in the case of a driver or service error.
(you may share resouces using 9p)
about inferno's GUI look
-------------------------
if you can - do it. if you like it, then it is also popular with someone else. there is no perfect interface design. there is must have a choice. if you have ideas - draw them. first in the corel.
if you have a few ideas - draw them.
personally i like the design of WeTab (but this will have to do a lot) and the design of my xubunu (xfce)
@ethan @hiro
i will see to aan. actually i don't know what to say about this. but will see. bad connections is a problem for IoT systems.
condolences to your pants. I hope it all ended well?
especially for you and everyone else, a collection of donations for work on the inferno and its expansion opens. who how much can! who at all can not - $1, who can a little - $10, who can - $100, who can well - $1000. Also donations of $10'000 and above are accepted.
donate. all your money will work for you, for your success, for your services and programs. one program - many platforms! and without brakes!
bhgv
https://github.com/bhgv/Inferno-OS-bhgv
inferno os tree was separated from inferno-android. it is tested to build on linux (bld-lin.sh) and windows (mk install). but you should still to configure mkconfig, makemk etc.
it includes all changes for android: ttf and png in Tk, devgui, autosizing, but doesn't include android wrapper.
in the future i will base on this repo
John Floren
> streaming extensions to 9p
> ---------------------------
> hmm, that do you mean? like an internet radio?
> you may do this on the regular 9p/styx. without any extensions.
> for example, all graphical operations go to/from devdraw. then you open a window - it opens devdraw files, then you close the window - it closes opened devdraw files. this frees all the associated with this window resources.
> file in the inferno is not a just file with size. it is a named channel. do with it what you want.
>
semantics. Consider 'cp'. It opens a file, then enters a loop where it
reads 8K from the source and writes it to the destination. Each read
is a 9P TREAD followed by an RREAD, similarly each write. If
round-trip time is, say, 100ms, that means it takes at least 400ms for
cp to copy 8K of data.
The idea of "streaming 9P" is that we should essentially pre-read from
the file; so when cp does an open on a file, the client immediately
prefetches the first megabyte of data, meaning read calls will
complete faster. Doing this transparently can cause some problems with
synthetic files, though--what does it mean to pre-cache /dev/time?
My master's thesis covered these topics and presented one possible
solution: adding explicit calls to say "I intend to read this file
straight through from beginning to end, so please stream it", which
generally gets around the problem of implicit caching. I don't pretend
it's the correct solution, but the document contains a summary of the
problem and some other solutions people have tried (including Op, I
hope I did it justice), so it may be of interest:
http://scholarworks.rit.edu/cgi/viewcontent.cgi?article=4100&context=theses
john
bhgv
small notes about the buffer sizes for 9p ops devread/devwrite:
-----------------------------------------------------------------------------------
qid.path (unsigned long long) is used for binding between calls. and it is transmitted in messages. it should be unique for the device/transaction, but no more requirements. the handle of the stream + the address of the top of the stack of buffers (or the address of the structure with the handle stream and the top of the stack) will be fine.
i think, to make a new Styx-device for continuous transmission and reception, taking as a basis a simple server like devaudio will be much easier, faster, more portable and will give fewer errors than the change of the Styx-protocol. also, it can be done in Limbo.
bhgv
i apologize for delay in inferno-works. i remember about aan and multithreaded styx, but now i absolutely do not have a time.
chris glur
You may be married to github.
But we are NOT.
Try to use standard *nix syntax.