Hello, Supragya. 2017-03-26 21:59 GMT+02:00 Supragya Raj <[email protected]>:
> Hi, > This is my proposal for GSoC 2017. I am trying to implement a scripting > system with reset functionality and core bdsh revampment in this project. > The scripting system will be highly influenced by sysel programming > language. > > Attached with this e-mail is the GSoC proposal (both *.odt and *.pdf) > which elaborates on how the system may be implemented. Can u provide with > valuable feedbacks? > Here are my comments for your proposal. Some of the issues I write about are probably caused be my misunderstanding of your proposal. Do not hesitate to say when it is so :-). I will start with a very generic question; I tried to keep the rest of the comments sorted as in your proposal. What you expect would be stored in the variables? Obviously, the l$var are plain variables to be used in the scripts, but what about the rest? Would we use them to store things like $PATH only or would they serve as a generic configuration storage (e.g. like registry in Windows)? !~script notation. The inspiration by Unix #! is obvious but I miss how would you distinguish different languages (or their interpreters). Why not to stick with the Unix format here? But this is a minor thing only. Variables and scopes. On one hand I like the idea of explicitly specified scope but it seems to me as actually not very practical. Consider for example some equivalent of $PATH. Sometimes you want to modify system-wide settings, sometimes you want some changes to be for current process only. Then the script would need to check for both e$PATH and b$PATH before running anything which is not very straightforward. Not talking about local variables in functions. Just by the way, I would stick with system-wide variables name instead of environment, because for Unix world, your bdsh-instance variables are actually environment ones. Which types do you plan to support and how? Because in 1.2 you wrote that "everything is a string" yet many of the examples use integers. Would there be some kind of automatic conversion (as in PHP, for example)? Have you thought about some structured types (arrays, maps, ...)? Use of Sysel. Although it is nice to reuse existing code base I would recommend to think again whether to re-use Sysel. Sysel was last updated 5 years ago and AFAIK is for all practical means abandoned. Since you already use different syntax in your examples, I do not think that you would reuse that much code. Furthermore, I think it is much better to use lexer/parser generators (e.g. Flex, Bison etc.) than to write them manually (especially if the syntax is expected to evolve). Similarly, I would probably create a new application (i.e. keep Bdsh as is). I suspect that the architectural changes in Bdsh would be too big and you can always copy functional parts of Bdsh to your app. I have a question regarding your example with l$var1 and pwd. What is pwd? Is that a built-in function or do you plan to capture output of a pwd command? By the way, how do you plan to support functions? Related to this: do you plan to reuse the IO redirection syntax from Bdsh? System restore: I really like the notion of transactions but I do not think that it is that simple. Although I understand that touch/rm served as a mere illustration it shows well the complexity of the problem: you would need some kind of snapshot support from the file system merely to allow rollback of FS-related operations. That alone would be worthy a GSoC project. So although it sounds very interesting I would remove this from your proposal. Variable management and storage. First of all, I would keep separate the POSIX-like environment variables that has very precise rules for scoping and inheritance among processes: implementing this as a separate server seems to me as a sensible solution. Second thing - implementing any variable storage like a file on a tmpfs looks like a bad idea. Either implement that in Bdsh directly or have a special server for that. Regarding your time-line. I think that it is basically okay but maybe if you decide to change the way variables are stored (i.e. get rid of that tmpfs approach) and remove the anti-command subtopic, some changes would be necessary. I hope this helps, looking forward to your comments! Cheers, - Vojtech > > I am looking for feedbacks especially on the following lines: > 1. Is the problem statement clearly defined? Does it makes sense? > 2. Does the solution seem plausible / understandable? > 3. Is the timeline unrealistic? > 4. Are additional systems required to be implemented in the project? > 5. Is section containing alternative pathways and risk assessments okay? > > Any other kind of feedback is also welcomed. > > Regards, > Supragya Raj > > > _______________________________________________ > HelenOS-devel mailing list > [email protected] > http://lists.modry.cz/listinfo/helenos-devel > >
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
