Skip to Content.
Sympa Menu

sm-users - Re: [SM-Users] menuconfig for casts

sm-users AT lists.ibiblio.org

Subject: Sourcemage Users List

List archive

Chronological Thread  
  • From: Thomas Orgis <thomas-forum AT orgis.org>
  • To: sm-users AT lists.ibiblio.org
  • Subject: Re: [SM-Users] menuconfig for casts
  • Date: Sat, 17 Dec 2005 02:41:56 +0100

Am Fri, 16 Dec 2005 17:58:54 -0200
schrieb Arthur Nascimento <tureba AT gmail.com>:

> I agree with Thomas on every aspect so far: answering to the very same

Thanks for the support;-)

> If I may be so bold, I am quite sure Andrew doesn't really mean
> turing-complete. We all know very well what turing completeness means
> and what a universal turing machine is. I know we all are or have been
> computer science or mathematics students, but I will remind us what

I can't resist throwing in here that I have indeed some understanding of the
term turing machine, but this is because of discussions with a computer
science student that happens to share the flat with me. For myself, I have
not and won't study computer science ot mathematics. The mathematics I
learned and the computer science I practice during my study of physics are
enough for me;-)


> it goes against the flow of SMGL right now. As Andrew noted, SMGL is
> proud of its dynamicity, while the way you are suggesting (and that I
> support) would need lots of things to be static, such as it is with

Actually, I have a very dynamic menu in mind... Probably we'd have to discuss
what kind of dynamics are really meant, but I still think that you can code
it into a coherent system. Don't nail me on the GUI on kernel's menuconfig -
the main point is changing the config from linear to random access, what
means robust and repeatable/reversable (two-way) processing of dependencies
between packages and chosen options. One knows the dependency resolution from
rpm managers for static dependencies. One can argue that SMGL is totally
different because the package relations aren't fixed but depend on
configure-time choices. But the existence of these choices is fixed. the
logic is quite similar to rpm when you don't consider package X depending on
package Y but package (X with enabled option) depending on package Y.
Each spell would correspond to a set of packages ( with option / without
option)... just a quick thought; not how far this analogy goes, but in every
normal case, a spell should not invent questions out of the blue. They could
be considered static.

> theory and algorythms (which is possibly to become the thesis of my

algo-rythm... you prefer the musical spelling, eh? Mostly, I read algorithm.

> Moreover, I have tried to install SMGL 4 or 5 times in the past and I
> never get it finished because of some compile errors in various places

OK, I have 4 installs now in various stages of completeness. Sadly, every one
showed new problems to solve (many by using a spell from test grimoire, which
probably is much better tested than stable - SMGL needs some "normal" users,
I guess). I went on to solve these problems because I tend to persist (and
pester) on the occasion - like you can see on my post count;-)


Thomas.




Archive powered by MHonArc 2.6.24.

Top of Page