Fwd: Expos

[Murali Krishnan]

Nikhil, Fariz,

   There is an error report.  When a file of strings is loaded through xfs interface, it seems each character is stored in a word

(instead of a line per word).   Consequently, the sorting program sorts characters rather than strings.

Could you please check. 

Murali

---------- Forwarded message ---------
From: varunkumar reddy.ramireddy <varunkumar...@nitc.ac.in>
Date: Tue, Oct 15, 2019 at 5:21 PM
Subject: Expos
To: Murali Krishnan <kmu...@nitc.ac.in>

Dear sir,

We cannot create an executable file (lu.xsm) to list all the users as asked in stage 26.

Also, sorting integers read from a file does not work as expected. Please see the attached program for bubble sort.

Thank you,

Varun.

[Nikhil Sojan]

Sir, 

We will check it today

Nikhil

--
You received this message because you are subscribed to the Google Groups "XOS Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xos-developer...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/xos-developers/CAEp%2Bu%2BwYsYfUCdRy5HECb3FP4Y4Gbu86y-6ZK2Mxgf9CChWFFg%40mail.gmail.com.

[Nikhil Sojan]

Sir,

Expos is storing each 16 characters in the data file into a word in the disk block when a data file is stored from xfs-interface.The disk doesn't know that each line is an integer. So we think the bubble sort implementation must check to go till the end of each line and convert each line to an integer and store it in an array and then sort it.Otherwise it will be sorted like strings as in, 1, 10, 100, 11....2, 20, 21....9, 90, 91...so on.But since each 16 characters are stored into a word, multiple numbers can be stored as a string in a block word.So in the bubblesort implementation by varun, reading from the file must happen character by character but we dont quite understand how all the numbers are read from 1-100 and sorted like strings.we discussed this with arun and he said he is free this weekend and we will fix it over this weekend.

Nikhil

[Arun Joseph]

Sir,

I think adding an option to allow loading .dat files as numbers itself (using something like "load --num") in the XFS-interface would be a good solution. If this is fine, I'll create a patch today itself.

Regards,

Arun Joseph

[Faris Shajahan]

But isn't that incorrect from a design point of view? Files stored must either be plain text or binary. I think the sorting algorithm is the one to be changed as a differentiation between numbers and character data comes only in such a higher level of abstraction. It is the duty of the OS programmer to understand that data stored in memory from a .dat file is just ASCII and convert data accordingly before processing it.

Faris.

--

You received this message because you are subscribed to the Google Groups "XOS Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xos-developer...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/xos-developers/da898f2c-f6dd-474d-a852-85e209c4a2c0%40googlegroups.com.

[Arun Joseph]

Yes. The reason why it's sorting like that is because the numbers are stored as "1\n", "2\n", etc. So, modifying the XFS-interface, such that it removes the "\n" if it is the last character also solves the problem. As eXpOS doesn't allow string manipulations, the user (eXpL programs) should be able handle strings and numbers in a similar way from files loaded using XFS-interface and those created via eXpOS.

[Faris Shajahan]

What I meant is it would be incorrect to load a file containing numbers as load --num or something. What if later we add an assignment question involving a file containing both numbers and strings? Then we would have to write another option for load and this would just go on. Hence it is the OS programmer and not the machine that who should differentiate between how number data and strings from the storage.

Faris.

On Sat, Oct 19, 2019, 12:07 Arun Joseph <arunjo...@gmail.com> wrote:

Yes. The reason why it's sorting like that is because the numbers are stored as "1\n", "2\n", etc. So, modifying the XFS-interface, such that it removes the "\n" if it is the last character also solves the problem. As eXpOS doesn't allow string manipulations, the user (eXpL programs) should be able handle strings and numbers in a similar way from files loaded using XFS-interface and those created via eXpOS.

--

You received this message because you are subscribed to the Google Groups "XOS Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xos-developer...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/xos-developers/7da6b46a-1bd4-46d6-a68b-df68aad4735c%40googlegroups.com.

[Nikhil Sojan]

Hey,  

As of now removing the '/n' works. So shouldn't it be okay to continue storing datafiles as strings in each disk word? 

To view this discussion on the web, visit https://groups.google.com/d/msgid/xos-developers/CADH%3DF4-GOL6NXrzrbVJTegKH3DNLdqiKtdCSnZ14OaHzatx1Uw%40mail.gmail.com.

[Karunakaran Murali Krishnan]

Let me try put things in the way it was originally intended  by the design. 

Suppose 32 is stored in a word on the disk by  xfs interface, I assume that it is stored as 32\n.  Am I right? 

(If that is not so, then having a load --num option could be added!). 

What I said above \seems to be the correct representation.  That is because the machine stores everything as strings.  (XSM is a string machine). 

So, the number 32 must be seen as the string "32\n" by the machine. 

Now, arithmetic instructions must operate on  strings interpreting the argument strings as \n terminated numbers. 

For instance, if R_0 contains "2\n" and R_1 contains "3\n", then ADD R_0,R_1 should put "5\n" into R_0.

There is no confusion here because the operator ADD is not overloaded.  ADD is defined only in this way.    

(If the arguments are not of the form NUM\n, NUM\n, the machine must throw exception). 

By definition, a string is a sequence of characters that ends on \n.  (If a string in a file that is being loaded is too long -  like "abcdefghijklmnop\n"

then,  the --load instruction of the xfs interface will be forced to either truncate the string and  load it as "abcdefghi\n" or

split it into two strings and load it as two consecutive words  "abcdefg\n" and  "jklmnop\n".   I think the latter convention is is being followed now.  

(That is, cut the string at the appropriate length cut off and write the remaining as a next string). 

Now, if a file contains 32\n 55\n 66\n 77\n, then the file should be properly treated as a file containing integers for the arithmetic operations. 

Now, where exactly things are failing?    Is the present system working according to the above specification? 

1.  If we create a text file in Unix, 32\n 44\n 55\n 66\n   won't xfsinterface load it correctly? 

2.  If we wish to provide the user a support to create her/his file  as  32 44 55 66   then we can provide a load --num option. 

Murali

To view this discussion on the web, visit https://groups.google.com/d/msgid/xos-developers/CAKZYgtouf0qhbpj_0wm1Ade3avntM19XLUm98yG7wnM0mhw%3DcA%40mail.gmail.com.

[Nikhil Sojan]

Sir, 

Expos does store numbers as 32/n 55/n etc.. in different words. But when chexking for the type of the data in a word, any character other than 0-9 will make the data type string.So the '/n' at the end would mean numbers are also treated as strings. Storing numbers without the '/n' would actually allow numbers to be treated as integers itself. 

Nikhil

To view this discussion on the web, visit https://groups.google.com/d/msgid/xos-developers/CAEkxZPM%3D1mUVaFWkdnt19QxQVR2M2V%3Dwatznf3zXHWZsZDqOBA%40mail.gmail.com.

[Faris Shajahan]

Instead can we change the definition of a string to be terminated by \0?

To view this discussion on the web, visit https://groups.google.com/d/msgid/xos-developers/CAKZYgtqZ55s48TW%2B%2BfPxGwZxiM5erEf7chrte-TSMhNDiHPXQA%40mail.gmail.com.

[Arun Joseph]

Strings are stored as "1\0". But when we load a file, 

1

2

3.

It gets stored as "1\n\0", "2\n\0", etc. We just need to remove the \n if it's before the end of string, \0.

To view this discussion on the web, visit https://groups.google.com/d/msgid/xos-developers/CADH%3DF4_rHSwExxk_8G_HfLV12TcmJcvTNK-u%3DQt1Ud7djd2Ceg%40mail.gmail.com.

[Arun Joseph]

Also, when we export a file, the newline (\n) we removed will be added back while creating a Linux file.

So, from Linux -> eXpOS, we need to remove the \n. And from eXpOS -> Linux, it is added back.

This allows us to load a list of numbers and strings as well.

Also, "load --num" is not required and this fix (removing \n from end of string) should be added while loading all .dat files.

A feature like "load -num" is only required if we give support for space separated integers, which is not required. Space separated integers should be considered as strings.

[Murali Krishnan]

Fine, I think the fix is clear now.  So, all strings are stored (integer or not) in the form "string\0".  

In that case, if R0="5\0" and R1="7\0"  then ADD R0 R1 will put "12\0" in R0.  Right?  

We need not support space separated numbers, as we can ask the user to create data files using line separators. 

Hope there are no unclear points left out. 

--

You received this message because you are subscribed to the Google Groups "XOS Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xos-developer...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/xos-developers/897e3b89-29cb-40fc-8b4d-47450768a0a0%40googlegroups.com.

[Faris Shajahan]

Sir,

The updated package with Nikhil's and Arun's proposed fix has been pushed to the eXpOSNitc.github.io repository in a different branch.

I am still a little skeptic about the fix as I feel it is the compiler that must typecast "5\0" to 5 according as the variable in context is of type int or not.

I shall merge the current fix with your confirmation.

Faris.

To view this discussion on the web, visit https://groups.google.com/d/msgid/xos-developers/CAEp%2Bu%2BwMvsUrFJ5o-kD8dakzjNwFU9aaPjQ94WpKicr0tF5S1g%40mail.gmail.com.

[Murali Krishnan]

We will discuss and finalize.
Murali

>>> <https://groups.google.com/d/msgid/xos-developers/897e3b89-29cb-40fc-8b4d-47450768a0a0%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .

>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "XOS Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to xos-developer...@googlegroups.com.
>> To view this discussion on the web, visit

>> https://groups.google.com/d/msgid/xos-developers/CAEp%2Bu%2BwMvsUrFJ5o-kD8dakzjNwFU9aaPjQ94WpKicr0tF5S1g%40mail.gmail.com
>> <https://groups.google.com/d/msgid/xos-developers/CAEp%2Bu%2BwMvsUrFJ5o-kD8dakzjNwFU9aaPjQ94WpKicr0tF5S1g%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .

>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "XOS Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to xos-developer...@googlegroups.com.
> To view this discussion on the web, visit

> https://groups.google.com/d/msgid/xos-developers/CADH%3DF48tYhvNTARg5cY0VTGpNbcMYmi1ts1Jsw4DFeEeWfL3aw%40mail.gmail.com.
>