Re: [dev] [st] will global-less changes be wanted upstream?
> The emulation in a terminal emulator is pure graphics. That???s why it is > a terminal emulator for a graphical environment. The logic behind it are > just flags to serve xdraws(). You will have to rewrite everything in a > new environment, especially because of the event infrastructure in X11. > There is not much to modularize here. I think all the sequence decoding logic is indendent of X, and almost of the sequence actions are also independent of X because they work in the line buffer and dirty buffer. In some way, these buffers are decoupling both parts. Regards, -- Roberto E. Vargas Caballero
Re: [dev] [st] will global-less changes be wanted upstream?
Good luck.
Re: [dev] [st] will global-less changes be wanted upstream?
On 8/17/14, 7:38 PM, Alexander Huemer wrote: > Well, as you may notice it's quite important for some people to get this > message through. You should be glad that there are people who give > advice. This advice is, once again: Don't use OSX, don't port good > software to OSX (and Windows). Sorry, I'm not going to be miserable when I use OS X. So I will continue to do what is necessary to recreate my preferred environment there, or anywhere. If you would like to prevent this usage, change the license.
Re: [dev] [st] will global-less changes be wanted upstream?
> I think this is a very nice summary of the situation. Are you maybe > aware of a webpage or some other text that describes this, maybe with > some code snippets, etc.? Well, I have searched some references in the net, but this is a really well known topic. You can read the description of rfork in freebsd [1] and Plan9 [2], and also you can read this page [3], where I quote it: A region in the main memory is ultimately loadded from the contents of the executable file (generated by the compiler). This file also is a part of the UNIX file system and is uniquely identified by an inode number. Thus, the region table also contains a pointer to this inode to trace back to the source from which the region was loaded. It needs the inode number to can share this region with another process that execute the same file, and then load the same read only pages. This is the reason why in some systems (old systems), you cannot modify the executable of one process that is runnning (yes I had to work in such systems and it was paintful :(). Regards, [1] http://www.freebsd.org/cgi/man.cgi?query=rfork [2] http://swtch.com/plan9port/man/man3/rfork.html [3] http://books.google.es/books?id=dY25RaFVM9oC&pg=PA615&lpg=PA615&dq=unix+inode+process+share+text+region&source=bl&ots=bzIN1Dqk2C&sig=BK7BEZsctf5Voq9zp79y1Lk4ooE&hl=es&sa=X&ei=XNjxU-y2OMmb1AXQtoDICw&ved=0CDQQ6AEwAw#v=onepage&q=unix%20inode%20process%20share%20text%20region&f=false -- Roberto E. Vargas Caballero
Re: [dev] [st] will global-less changes be wanted upstream?
On Sun, Aug 17, 2014 at 10:12:13PM +0200, Roberto E. Vargas Caballero wrote: > Sorry, it is efficient due to text sharing and, in some cases, to > copy on write. When you run multiple instances of a static linked program > usual OS make that all these process share the pages of the text segment. > If all the process are spawn from a common parent then they also share > data pages until they modified them (that sometime is never). you can see > that dynamic linking doesn't help in this case (same instances of the > same program). Dynamic libraries can help sharing pages between process > of diferent executables. Thanks for that, your pedantry is welcome. I ignored this text sharing feature of operating systems, I thought only the libraries pulled in were shared. Best, -- q
Re: [dev] [st] will global-less changes be wanted upstream?
On Sun, Aug 17, 2014 at 06:22:55PM -0500, Steven Degutis wrote: > > Don't make yourself at home on OSX! > > Obviously we're all entitled to our own opinions. But this discussion > has gotten very far off-track. My original question was answered > satisfactorily already, so this thread is largely "OS X sucks and only > fools use it" over and over, which is a waste of everyone's time. Well, as you may notice it's quite important for some people to get this message through. You should be glad that there are people who give advice. This advice is, once again: Don't use OSX, don't port good software to OSX (and Windows). Kind regards, -Alex
Re: [dev] [st] will global-less changes be wanted upstream?
>> > The world you're living in is the walled garden of OS X. >> > It's your choice to either attempt to improve it, which is futile, or >> > enter a world in which improvement is possible in the first place. >> >> I have to use OS X sometimes for work. > > I have to too, from time to time. > >> It's still a general-purpose operating system, and you can still run >> arbitrary programs on it. > > That's true, but you don't aim very high here. > >> It is closer to BSD than Linux, aside from the GUI layer. > > No. OSX is not usable for anything without the proprietary pieces. I > personally don't trust a system that needs blobs to run, and I think > that's the way to go. > >> But it ships with a working X server, and it has a working C compiler, >> so st worked fine until a few commits ago right out of the box. > > Don't make yourself at home on OSX! > >> I use it when I use OS X because I like using the same tools >> everywhere. > > Don't make yourself at home on OSX! > >> And I use suckless tools because their simplicity makes them easy to >> port everywhere. > > Don't make yourself at home on OSX! > >> I will never be at home the way one can be in a system built one's >> self, but my preferred working environment is not so complex that I >> can't replicate it almost anywhere I need it. So regardless of >> Steven's goals, I appreciate his efforts that will, in the end, make >> the time I spend wading in the GUI sewage of OS X so much less >> painful. > > Don't make yourself at home on OSX! Obviously we're all entitled to our own opinions. But this discussion has gotten very far off-track. My original question was answered satisfactorily already, so this thread is largely "OS X sucks and only fools use it" over and over, which is a waste of everyone's time.
Re: [dev] [st] will global-less changes be wanted upstream?
On Sun, Aug 17, 2014 at 10:12:13PM +0200, Roberto E. Vargas Caballero wrote: > On Sun, Aug 17, 2014 at 09:22:31PM +0200, q...@c9x.me wrote: > > This is OS X specific and weird in my opinion, if you want multiple windows > > lauch multiple processes. It is safer, you can limit the impact of a crash > > to a single window. It is also memory efficient thanks to (haters gonna > > hate) dynamic link. > > Sorry, it is efficient due to text sharing and, in some cases, to > copy on write. When you run multiple instances of a static linked program > usual OS make that all these process share the pages of the text segment. > If all the process are spawn from a common parent then they also share > data pages until they modified them (that sometime is never). you can see > that dynamic linking doesn't help in this case (same instances of the > same program). Dynamic libraries can help sharing pages between process > of diferent executables. I think this is a very nice summary of the situation. Are you maybe aware of a webpage or some other text that describes this, maybe with some code snippets, etc.? Kind regards, -Alex
Re: [dev] [st] will global-less changes be wanted upstream?
On Sun, Aug 17, 2014 at 06:00:54PM -0400, Andrew Hills wrote: > On 8/17/14, 3:47 PM, FRIGN wrote: > > The world you're living in is the walled garden of OS X. > > It's your choice to either attempt to improve it, which is futile, or > > enter a world in which improvement is possible in the first place. > > I have to use OS X sometimes for work. I have to too, from time to time. > It's still a general-purpose operating system, and you can still run > arbitrary programs on it. That's true, but you don't aim very high here. > It is closer to BSD than Linux, aside from the GUI layer. No. OSX is not usable for anything without the proprietary pieces. I personally don't trust a system that needs blobs to run, and I think that's the way to go. > But it ships with a working X server, and it has a working C compiler, > so st worked fine until a few commits ago right out of the box. Don't make yourself at home on OSX! > I use it when I use OS X because I like using the same tools > everywhere. Don't make yourself at home on OSX! > And I use suckless tools because their simplicity makes them easy to > port everywhere. Don't make yourself at home on OSX! > I will never be at home the way one can be in a system built one's > self, but my preferred working environment is not so complex that I > can't replicate it almost anywhere I need it. So regardless of > Steven's goals, I appreciate his efforts that will, in the end, make > the time I spend wading in the GUI sewage of OS X so much less > painful. Don't make yourself at home on OSX! Go and read [1]. Kind regards, -Alex [1] http://www.fefe.de/nowindows/
Re: [dev] [st] will global-less changes be wanted upstream?
On Sun, Aug 17, 2014 at 09:47:48PM +0200, FRIGN wrote: > The world you're living in is the walled garden of OS X. > It's your choice to either attempt to improve it, which is futile, or > enter a world in which improvement is possible in the first place. I agree very much with this (generalized) idee, and other people do too. See e.g. [1]. There is no excuse to use something like OSX on *purpose*. There is no way to improve this ecosystem, it will never be free and open. Porting a piece of wonderful software to such a platform only helps to create an illusion of a nice system. Kind regards, -Alex [1] http://www.fefe.de/nowindows/
Re: [dev] [st] will global-less changes be wanted upstream?
On 8/17/14, 3:47 PM, FRIGN wrote: > The world you're living in is the walled garden of OS X. > It's your choice to either attempt to improve it, which is futile, or > enter a world in which improvement is possible in the first place. I have to use OS X sometimes for work. It's still a general-purpose operating system, and you can still run arbitrary programs on it. It is closer to BSD than Linux, aside from the GUI layer. But it ships with a working X server, and it has a working C compiler, so st worked fine until a few commits ago right out of the box. I use it when I use OS X because I like using the same tools everywhere. And I use suckless tools because their simplicity makes them easy to port everywhere. I will never be at home the way one can be in a system built one's self, but my preferred working environment is not so complex that I can't replicate it almost anywhere I need it. So regardless of Steven's goals, I appreciate his efforts that will, in the end, make the time I spend wading in the GUI sewage of OS X so much less painful.
Re: [dev] [st] will global-less changes be wanted upstream?
Sure, I already groked that you was meaning the postpostpostpostpostnextSTEP environment for the whateverapp store (don't read this in a mocking tone on your efforts in this system, it isn't intended at all). Well this really is enlightening about Mac OS, thank you. Under these constrainments, though, it seems to me you'll have to reinvent mxterm or rxvt with tabs. Or adding, like, a terminal mux in the program. And this is a lot more than just porting st to Mac OS X. Good luck! -- Teodoro Santoni
Re: [dev] [st] will global-less changes be wanted upstream?
> On Sun, 17 Aug 2014 22:35:27 +0200 "Roberto E. Vargas Caballero" > wrote: >> > I think it would also be beneficial because it is difficult (at least >> > for me) to keep track of a single ~4k line c file. >> >> I usually work in the terminal emulation part, and sometimes it is a >> bit confusing mix the code of this part with the graphical part. >> What do you think about this topic guys? > > The emulation in a terminal emulator is pure graphics. That’s why it is > a terminal emulator for a graphical environment. The logic behind it are > just flags to serve xdraws(). You will have to rewrite everything in a > new environment, especially because of the event infrastructure in X11. > There is not much to modularize here. > > Having one server for many windows is what was first planned as an > urxvt‐like daemon feature. The complexity in code for this does not re‐ > ally give much gain. So it was dropped. After carefully teasing the X parts away from the terminal emulation parts of st.c, I now have a term.c[1] file with only 1740 lines and term.h[2] with 238 lines. So terminal emulation, without regard to any GUI, only accounts for roughly half of the lines of st.c. [1] https://github.com/sdegutis/hammerterm/blob/master/Hammerterm/term.c [2] https://github.com/sdegutis/hammerterm/blob/master/Hammerterm/term.h -Steven
Re: [dev] [st] will global-less changes be wanted upstream?
Greetings. On Sun, 17 Aug 2014 22:35:27 +0200 "Roberto E. Vargas Caballero" wrote: > > I think it would also be beneficial because it is difficult (at least > > for me) to keep track of a single ~4k line c file. > > I usually work in the terminal emulation part, and sometimes it is a > bit confusing mix the code of this part with the graphical part. > What do you think about this topic guys? The emulation in a terminal emulator is pure graphics. That’s why it is a terminal emulator for a graphical environment. The logic behind it are just flags to serve xdraws(). You will have to rewrite everything in a new environment, especially because of the event infrastructure in X11. There is not much to modularize here. Having one server for many windows is what was first planned as an urxvt‐like daemon feature. The complexity in code for this does not re‐ ally give much gain. So it was dropped. Sincerely, Christoph Lohmann
Re: [dev] [st] will global-less changes be wanted upstream?
On Sun, Aug 17, 2014 at 09:22:31PM +0200, q...@c9x.me wrote: > This is OS X specific and weird in my opinion, if you want multiple windows > lauch multiple processes. It is safer, you can limit the impact of a crash > to a single window. It is also memory efficient thanks to (haters gonna > hate) dynamic link. Sorry, it is efficient due to text sharing and, in some cases, to copy on write. When you run multiple instances of a static linked program usual OS make that all these process share the pages of the text segment. If all the process are spawn from a common parent then they also share data pages until they modified them (that sometime is never). you can see that dynamic linking doesn't help in this case (same instances of the same program). Dynamic libraries can help sharing pages between process of diferent executables. Regards, -- Roberto E. Vargas Caballero
Re: [dev] [st] will global-less changes be wanted upstream?
> I am interested in a separation of terminal and windowing system logic > for my wayland port[0] of st. ... You did something like this in the past, didn't it?. > That said, I don't really see how moving globals into a Term structure > would help with this. I think you could accomplish this by moving any > X-related code to an x.c, and then you could drop in a wayland.c or > whatever.c, and have config.mk choose which one gets built into st. Well, I think the problem is to do this work without complex interfaces that convert the code in suck code. If such interfaces exit maye colud be a good idea. > I think it would also be beneficial because it is difficult (at least > for me) to keep track of a single ~4k line c file. I usually work in the terminal emulation part, and sometimes it is a bit confusing mix the code of this part with the graphical part. What do you think about this topic guys? > [0]: https://github.com/michaelforney/st.git You work is really good!, please continue with it!, Regards, -- Roberto E. Vargas Caballero
Re: [dev] [st] will global-less changes be wanted upstream?
On Sun, 17 Aug 2014 14:30:19 -0500 Steven Degutis wrote: > I just read this to my wife and she paraphrased your comment I think > pretty accurately: "so, don't improve the world you're in, just live > with it". Your wife knows dick. She assumes everyone is using OS X, which obviously is not the case. This argumentum ad consequentiam was only valid if I had no choice which OS to use. Here at suckless, we've already made our choice. So please don't poison us with this bullshit. > Well I can't really accept that recommendation, since I would rather > improve the world I'm living in than just leave it as-is. The world you're living in is the walled garden of OS X. It's your choice to either attempt to improve it, which is futile, or enter a world in which improvement is possible in the first place. With you accusing me of ignoring the problems in the world, you're a rather dramatic person unable to solve his own problems. Cheers FRIGN -- FRIGN
Re: [dev] [st] will global-less changes be wanted upstream?
>> > Who’s still using Apple software in 2014 should be considered a fool. >> > iPhones are open to everyone, Mac OS X is full of security holes, the >> > hardware is built by slaves in the third world. >> >> None of which is relevant to the task at hand. > > It is. > When you port something to an OS that is mostly used by fools, you are a fool. > > In a toxic environment like OS X, just use the provided Terminal emulator and > wait for the day you can finally switch to a UN*X-OS. > > End of story. I just read this to my wife and she paraphrased your comment I think pretty accurately: "so, don't improve the world you're in, just live with it". Well I can't really accept that recommendation, since I would rather improve the world I'm living in than just leave it as-is. -Steven
Re: [dev] [st] will global-less changes be wanted upstream?
> This is OS X specific and weird in my opinion, if you want multiple windows > lauch multiple processes. It is safer, you can limit the impact of a crash > to a single window. It is also memory efficient thanks to (haters gonna > hate) dynamic link. That's not how OS X users expect their apps to work. So I'm not going to go against the grain on this, I'm going to stick to existing conventions, which means one process and several windows. >> So, had these changes been made before I started my >> port, it would have saved me a day of working on it. But you're right, >> now that I've already done it, there's really no point in contributing >> it back to the original codebase. > > I sense an offensive tone here. > > You should not feel aggressed, people here are hard to convince and stronly > opinionated, it is healthy. In this case your change is of no interest for > the original st because the plateforms it targets have the ability to launch > the same application multiple times, that's all. You sensed slight irritation in my words, due to the fact that I did lose a day making these changes that might have been spared if they were already made. But I'm not really that upset. Like you and I have both said already, the changes I've made aren't really necessary upstream. Thus there's no real point to trying to contribute them back. That's all I was saying.
Re: [dev] [st] will global-less changes be wanted upstream?
On Sun, Aug 17, 2014 at 12:04:12PM -0500, Steven Degutis wrote: > [...] > in the same process, which the current architecture of the program > does not allow. Otherwise the application would be limited to only > ever having one terminal emulator open, which seems to me like a > severe limitation. This is OS X specific and weird in my opinion, if you want multiple windows lauch multiple processes. It is safer, you can limit the impact of a crash to a single window. It is also memory efficient thanks to (haters gonna hate) dynamic link. > So, had these changes been made before I started my > port, it would have saved me a day of working on it. But you're right, > now that I've already done it, there's really no point in contributing > it back to the original codebase. I sense an offensive tone here. You should not feel aggressed, people here are hard to convince and stronly opinionated, it is healthy. In this case your change is of no interest for the original st because the plateforms it targets have the ability to launch the same application multiple times, that's all. -- q
Re: [dev] [st] will global-less changes be wanted upstream?
> Stupid question by an ignorant prosumer: are you serious? You can have only > one > instance of something opened in Mac OS? Oops, I should clarify. This is only the case with graphical programs, which live within a .app directory, containing the actual executable and the resources for the program. Unix utilities on the other hand still work as normal, i.e. you can run cat or less just like you would in Linux, within a terminal emulator. I only meant this about GUI programs, which my port of st is one of.
Re: [dev] [st] will global-less changes be wanted upstream?
>> You're very right: There is no point to it anymore. The changes I've >> made are necessary for a straight-forward OS X port, because in OS X, >> applications have only one instance, but may have many windows; thus >> if you wanted to open multiple terminals, they would all need to live >> in the same process, which the current architecture of the program >> does not allow. Otherwise the application would be limited to only >> ever having one terminal emulator open, which seems to me like a >> severe limitation. > > Stupid question by an ignorant prosumer: are you serious? You can have only > one > instance of something opened in Mac OS? Slightly. You can force new instances in various ways, such as with `open -n`. But it's not the recommended way to run programs. Instead, an application acts very much like a lightweight server, where it can have several windows but they all live in the same process. It's a different architecture than how it works on Linux or Windows, but it has its own advantages.
Re: [dev] [st] will global-less changes be wanted upstream?
On Sun, Aug 17, 2014 at 12:04:12PM -0500, Steven Degutis wrote: > You're very right: There is no point to it anymore. The changes I've > made are necessary for a straight-forward OS X port, because in OS X, > applications have only one instance, but may have many windows; thus > if you wanted to open multiple terminals, they would all need to live > in the same process, which the current architecture of the program > does not allow. Otherwise the application would be limited to only > ever having one terminal emulator open, which seems to me like a > severe limitation. Stupid question by an ignorant prosumer: are you serious? You can have only one instance of something opened in Mac OS? -- Teodoro Santoni Tel. 3312457594 asbras...@gmail.com IT consultant (Software, HW, Networking)
Re: [dev] [st] will global-less changes be wanted upstream?
On Sun, 17 Aug 2014 12:35:18 +0200 Markus Wichmann wrote: > > Who’s still using Apple software in 2014 should be considered a fool. > > iPhones are open to everyone, Mac OS X is full of security holes, the > > hardware is built by slaves in the third world. > > None of which is relevant to the task at hand. It is. When you port something to an OS that is mostly used by fools, you are a fool. In a toxic environment like OS X, just use the provided Terminal emulator and wait for the day you can finally switch to a UN*X-OS. End of story. Cheers FRIGN -- FRIGN
Re: [dev] [st] will global-less changes be wanted upstream?
On Sun, Aug 17, 2014 at 7:04 PM, Steven Degutis wrote: [...] > does not allow. Otherwise the application would be limited to only > ever having one terminal emulator open, which seems to me like a > severe limitation. [...] This. This is a feature. You're seriously suggesting to only have one terminal open ever? That's great, so I would always find my terminal multiplexer session on that window... cheers! mar77i
Re: [dev] [st] will global-less changes be wanted upstream?
On Sat, Aug 16, 2014 at 06:32:01PM -0500, Steven Degutis wrote: > > What is the point? > > One obvious cons is that it will bloat the code, make it less readable. > > First of all, I would not agree that it would bloat the code or make > it less readable. In fact I think it will increase readability, as > object structure and hierarchy will be more readily apparent. Plus, it > would make for a more clean and obvious separation of > responsibilities, such as terminal logic and logic for drawing to the > screen, &c. > > As a consequence, it might become easier for contributions to my fork > of the terminal logic (i.e. if my users submit bug fixes or new > features, &c.) to be merged upstream to st, where they would also be > relevant. I am interested in a separation of terminal and windowing system logic for my wayland port[0] of st. That said, I don't really see how moving globals into a Term structure would help with this. I think you could accomplish this by moving any X-related code to an x.c, and then you could drop in a wayland.c or whatever.c, and have config.mk choose which one gets built into st. I think it would also be beneficial because it is difficult (at least for me) to keep track of a single ~4k line c file. [0]: https://github.com/michaelforney/st.git
Re: [dev] [st] will global-less changes be wanted upstream?
> What is the point? You're very right: There is no point to it anymore. The changes I've made are necessary for a straight-forward OS X port, because in OS X, applications have only one instance, but may have many windows; thus if you wanted to open multiple terminals, they would all need to live in the same process, which the current architecture of the program does not allow. Otherwise the application would be limited to only ever having one terminal emulator open, which seems to me like a severe limitation. So, had these changes been made before I started my port, it would have saved me a day of working on it. But you're right, now that I've already done it, there's really no point in contributing it back to the original codebase. -Steven
Re: [dev] [st] will global-less changes be wanted upstream?
> You have patches? Just submit them. This kind of meta discussion isn't > worth anything. Very good point, thank you Alex. It sounds like my changes most likely won't be welcome, due to differences of opinion. And that's perfectly fine. If anyone is curious, here are the term.c and term.h files which I've extracted out from the rest of the code yesterday: https://github.com/sdegutis/hammerterm/blob/master/Hammerterm/term.h https://github.com/sdegutis/hammerterm/blob/master/Hammerterm/term.c -Steven
Re: [dev] [st] will global-less changes be wanted upstream?
Hi. On Sat, Aug 16, 2014 at 04:51:27PM -0500, Steven Degutis wrote: > I'm making progress on my port of st to OS X, and one of the changes > I'm making is to get rid of globals, turning most of them into fields > on Term, and making all the functions that use them take Term* as an > argument. It's a very minimal change, still very compatible with the > original st. Are these changes going to be wanted upstream? I see several problems here. * You have patches? Just submit them. This kind of meta discussion isn't worth anything. * You port a piece of *suckless* software (read that word in the asterisks again!) to a platform like OSX? Well, the discussion ends at this point. There is no point in doing so. The whole ecosystem of Apple Software isn't compatible with the mindset I experience on this mailing list. Also I don't see the benefit in having something like st on OSX. Kind regards, -Alex
Re: [dev] [st] will global-less changes be wanted upstream?
On Sun, Aug 17, 2014 at 08:56:45AM +0200, Christoph Lohmann wrote: > You are wrong. The approach to shuffle everything into object‐liked > structures is what makes software development ill. Stop it now. It would be hard for that statement to be more wrong, because what makes software development sick is not a drive towards organization. Anyone who ever tried to make zsnes run on a 64-bit machine should know that much: They never use anything but globals there. Although shuffling all the globals into a global super-object won't really help with that, it can help to actually analyze the data flow and make better optimizations. What makes software development sick is lasagna code that never get's simplified until runtime. So not only are you developing in a very high stack of rather fragile applications, that whole stack also has to run later on. (An example of having a high level of abstraction done right: Haskell. You won't know what exactly the compiler will make of your code, but it gets compiled to assembly and is not required to run your code). Otherwise, there's the bad habit of software companies to set really stupid coding rules (like "only use structured programming. Ever. No exceptions.") that fail to address the real problems (like 1000 line functions and code organization that would tear the souls of everyone with even the slightest background in software engineering asunder.) > The rea‐ > son why st is keeping this global is because there is no intention to > reuse the st object in your web page or on your iPad. > No-one wanted to do that. But keep up your straw-man burning over there! > Enforcing such »structure« keeps you from going the fast lane in effi‐ > cient code. > Benchmarks or it didn't happen. > The discussion on how terminals should evolve has happened on this mail‐ > inglist a while ago. No, it’s not reusing them everywhere and extending > the escape codes. > That is already possible in a relatively painless way in st. So again, you're burning a straw man here. > Your narcissistic Apple user. Come down from your white horse. Ascribing personality disorders to people is meaningless without a certified psychology education. Also, slightly ironic you should say that. > You > should contribute to st instead of forking it to an irrelevant platform > like Mac OS X. > You don't need it, therefore it's irrelevant. Classy. > Who’s still using Apple software in 2014 should be considered a fool. > iPhones are open to everyone, Mac OS X is full of security holes, the > hardware is built by slaves in the third world. None of which is relevant to the task at hand. > And if you try to use > the job joker, learn about virtualisation. In the times of quad core > CPUs and Gbit network you can run multiple instances of Linux every‐ > where. > Because when I think of running a terminal emulator, I think VMWare. Especially when trying to change stuff in the host. > > Sincerely, > > Christoph Lohmann > > Bye, Markus
Re: [dev] [st] will global-less changes be wanted upstream?
On Sat, Aug 16, 2014 at 04:51:27PM -0500, Steven Degutis wrote: > original st. Are these changes going to be wanted upstream? The procedure is to sent these changes to the mailing list and them they will be reviewed for all the members of the comunity and then the maintainers will take a decision about them, although the kind of changes you commented don't seem the kind of changes that are accepted. Regards, -- Roberto E. Vargas Caballero
Re: [dev] [st] will global-less changes be wanted upstream?
Greetings. On Sun, 17 Aug 2014 08:56:45 +0200 Steven Degutis wrote: > > What is the point? > > One obvious cons is that it will bloat the code, make it less readable. > > First of all, I would not agree that it would bloat the code or make > it less readable. In fact I think it will increase readability, as > object structure and hierarchy will be more readily apparent. Plus, it > would make for a more clean and obvious separation of > responsibilities, such as terminal logic and logic for drawing to the > screen, &c. You are wrong. The approach to shuffle everything into object‐liked structures is what makes software development ill. Stop it now. The rea‐ son why st is keeping this global is because there is no intention to reuse the st object in your web page or on your iPad. Enforcing such »structure« keeps you from going the fast lane in effi‐ cient code. The discussion on how terminals should evolve has happened on this mail‐ inglist a while ago. No, it’s not reusing them everywhere and extending the escape codes. > As a consequence, it might become easier for contributions to my fork > of the terminal logic (i.e. if my users submit bug fixes or new > features, &c.) to be merged upstream to st, where they would also be > relevant. Your narcissistic Apple user. Come down from your white horse. You should contribute to st instead of forking it to an irrelevant platform like Mac OS X. Who’s still using Apple software in 2014 should be considered a fool. iPhones are open to everyone, Mac OS X is full of security holes, the hardware is built by slaves in the third world. And if you try to use the job joker, learn about virtualisation. In the times of quad core CPUs and Gbit network you can run multiple instances of Linux every‐ where. Sincerely, Christoph Lohmann
Re: [dev] [st] will global-less changes be wanted upstream?
> What is the point? > One obvious cons is that it will bloat the code, make it less readable. First of all, I would not agree that it would bloat the code or make it less readable. In fact I think it will increase readability, as object structure and hierarchy will be more readily apparent. Plus, it would make for a more clean and obvious separation of responsibilities, such as terminal logic and logic for drawing to the screen, &c. As a consequence, it might become easier for contributions to my fork of the terminal logic (i.e. if my users submit bug fixes or new features, &c.) to be merged upstream to st, where they would also be relevant. -Steven
Re: [dev] [st] will global-less changes be wanted upstream?
> What were the changes that were specific to the port to OS X? This > particular change doesn't seem related to porting. You're right, this change isn't related to the port. As I'm doing my port, I'm changing existing code structure as I go along to make porting it a little easier (since AppKit is not very similar to X), but doing it all in the same repository (my port's repo). One of the planned changes is to reflect the current responsibility hierarchy in nested structs, with Term being at the top, and moving the other globals into it or some other struct that they would belong to. So yes, this change is not specific to OS X, but I'm doing all the work in the same repo. -Steven
Re: [dev] [st] will global-less changes be wanted upstream?
On Sat, Aug 16, 2014 at 04:51:27PM -0500, Steven Degutis wrote: > I'm making progress on my port of st to OS X, and one of the changes > I'm making is to get rid of globals, turning most of them into fields > on Term, and making all the functions that use them take Term* as an > argument. It's a very minimal change, still very compatible with the > original st. Are these changes going to be wanted upstream? What were the changes that were specific to the port to OS X? This particular change doesn't seem related to porting.
Re: [dev] [st] will global-less changes be wanted upstream?
On Sat, Aug 16, 2014 at 04:51:27PM -0500, Steven Degutis wrote: > I'm making progress on my port of st to OS X, and one of the changes > I'm making is to get rid of globals, turning most of them into fields > on Term, and making all the functions that use them take Term* as an > argument. It's a very minimal change, still very compatible with the > original st. Are these changes going to be wanted upstream? What is the point? One obvious cons is that it will bloat the code, make it less readable. -- q
[dev] [st] will global-less changes be wanted upstream?
I'm making progress on my port of st to OS X, and one of the changes I'm making is to get rid of globals, turning most of them into fields on Term, and making all the functions that use them take Term* as an argument. It's a very minimal change, still very compatible with the original st. Are these changes going to be wanted upstream? -Steven
