2969
|
1 2003-01-25.txt:18:57:15: <exarkun> d'you know if the stack stack is shared between threads in concurrent funge?
|
|
2 2003-01-25.txt:18:57:54: <fizzie> each has its own stack.
|
|
3 2003-01-25.txt:18:58:07: <exarkun> yea, each has its own stack
|
|
4 2003-01-25.txt:18:58:16: <exarkun> but the docs don't say anything about the stack stack
|
|
5 2003-01-25.txt:18:58:52: <fizzie> wellll.. stack is just what's on top of the stack stack.
|
|
6 2003-01-25.txt:18:59:23: <fizzie> in befunge97 or 96 they had shared stacks, which sounds really, really sick.
|
|
7 2003-01-27.txt:23:21:52: <lament> well if someone finds it offensive, fuck that btich!
|
|
8 2003-02-07.txt:05:06:00: <lament> "height in wavelengths"? What the fuck.
|
|
9 2003-04-20.txt:01:51:43: <lament> Many people who are into Scientology don't suspect how fucked up it is, either
|
|
10 2003-07-09.txt:04:09:41: <dbc> And I wouldn't broaden it too far. Stack machines are fine, but a four-function calculator isn't. Again, I'm trying to match common usage, which doesn't speak of "programming" anything very different from a computer...
|
|
11 2003-07-09.txt:04:13:19: <lament> In common usage, somebody says "HTML is a programming language, i learned it at school", and the response is "FUCK YOU!" *ban*
|
|
12 2003-07-12.txt:00:47:31: <andreou> power and shit...
|
|
13 2003-07-26.txt:04:25:32: <andreou> well, if i direct him to the UHH he'll start shouting at me ``what kind of the worst lamer has written that piece of trinary shit''
|
|
14 2003-07-30.txt:20:32:00: <lament> Taaus: so they wanted to rename the language to "fuck"
|
|
15 2003-08-06.txt:19:20:43: <lament> but THIS is fucked up
|
|
16 2003-09-04.txt:02:28:14: <lament> Therefore, timbre can go fuck itself!
|
|
17 2003-09-04.txt:02:53:42: <lament> very shitty music, certainly.
|
|
18 2003-10-21.txt:00:49:56: <lament> that wouldn't be fucked up enough
|
|
19 2003-10-21.txt:04:24:40: -!- lament has quit ("fuck").
|
|
20 2003-10-22.txt:03:32:16: <andreou> lament "ante gamisou" is "fuck off"
|
|
21 2003-10-22.txt:03:37:23: <stevaras> or a forgotten cut dick
|
|
22 2003-11-21.txt:02:32:43: <Taaus> I'm not sure.. It doesn't have any looping constructs, as far as I can see... Although it might be possible to implement it with a stack.. Hmm.
|
|
23 2003-11-21.txt:02:37:34: <Taaus> Cool. I made it blow the stack with a loop.
|
|
24 2003-11-21.txt:02:39:07: <Taaus> @+<coord> is "push <coord> onto stack", @@<coord> is "do <coord> for each item in stack"
|
|
25 2003-11-21.txt:02:41:41: <Taaus> A stack operation counts as a <coord>. And { ... } is just to group more <coord>s as one <coord>.
|
|
26 2003-11-21.txt:02:42:42: <Taaus> Well, the <coord> popped from the stack is placed in a special variable called the "current coordinate".
|
|
27 2003-11-21.txt:02:43:26: <Taaus> The @+ operation doesn't affect the current coordinate, but it does push its argument onto the stack.
|
|
28 2003-11-21.txt:02:59:07: <Taaus> I guess you could implement a kind of truth values using empty/non-empty stacks...
|
|
29 2003-11-21.txt:02:59:23: <Taaus> It's possible to save stacks in variables, BTW.
|
|
30 2003-11-21.txt:03:24:37: <lament> is a stack just a type of coordinate? :)
|
|
31 2003-11-21.txt:03:41:04: <Taaus> Grr... Saving stacks in variables seems to be... Limited, somehow... It seems it has to take place directly after the stack has been initialised.
|
|
32 2003-12-29.txt:21:56:40: <lament> any time you need more stack for example
|
|
33 2003-12-29.txt:21:56:57: <lament> neither does c, if you consider the stack
|
|
34 2004-02-08.txt:05:10:13: <lament> the whole terminology is extremely fucked up.
|
|
35 2004-02-08.txt:20:48:59: <Toreun> two dimensional, using a stack and a queue
|
|
36 2004-02-08.txt:20:58:38: <fizzie> er, with a stack and a queue, wouldn't the "obvious" way to do that be to stack everything from the queue to the stack, and then enqueue them back in the queue? (hee, that sounds fun. stack to the stack and enqueue in a queue.)
|
|
37 2004-02-08.txt:21:13:49: <Toreun> I'm probably gonna end up just using source-editing, so I can have the stack for other things
|
|
38 2004-02-08.txt:21:24:14: <fizzie> like that can't-remember-the-letter instruction in funge98 which pops the new delta vector from the stack.
|
|
39 2004-02-11.txt:00:16:55: <mooz-> I made a multitasking befunge befunge interpreter, but it doesn't keep the processes' stacks separate yet, making it quite useless
|
|
40 2004-02-11.txt:00:18:11: <fizzie> my glfunge98 knows how to multithread with separate stacks (using the funge98 multithreading instructions) but it's otherwise ultra-mega-sucky.
|
|
41 2004-02-11.txt:00:27:56: <Toreun> and the void is a stack with a max size of two
|
|
42 2004-02-13.txt:00:37:56: <calamari_> using c I could make a loop executing g() with void f() { g(); f() }, however, eventually the stack would overflow. I wonder if there's a way to avoid that without using "if" "while", "for", etc.
|
|
43 2004-02-13.txt:01:01:59: <Toreun> I'm thinking 'quack' because it has a queue and a stack
|
|
44 2004-04-29.txt:03:30:51: <Toreun> I talked about it awhile back here... it's a two dimensional programming language with a stack and a queue
|
|
45 2004-04-29.txt:06:08:52: <andreou> ah shit.
|
|
46 2004-04-30.txt:07:49:01: <heatsink> Well, brainfork is not actually known to be turing-complete; besides which brainfooey is not something any sane programmer would want to program in. For more info on brainfufu, look at the website (...). Of course, it's not actually called Brainflock, but we don't want to mention bad words and all that shit.
|
|
47 2004-04-30.txt:07:50:45: <lament> "And I can't quite make out that last one... And even if I could, i wouldn't say it. Because there're kids present, and I wouldn't want to fuck with their brains"
|
|
48 2004-04-30.txt:08:34:23: <lament> holy shit
|
|
49 2004-05-01.txt:04:05:28: <andreou> shit, yeah.
|
|
50 2004-05-04.txt:00:50:43: <andreou> by the way, the wikied code is stacked on my todo que (as #1), since i have to learn latex right now, i'll restart work on it tomorrow or the day after.
|
|
51 2004-05-27.txt:16:00:32: <fizzie> oh, and between '93 and '98 there was that funky funge with multithreading but a shared stack between all threads. (can't remember if it was '96 or '97)
|
|
52 2004-05-27.txt:16:06:04: <fizzie> they just push the corresponding number to stack.
|
|
53 2004-05-27.txt:16:06:30: <fizzie> there are no variables, just the stack. oh, and you can write/read to/from the playfield.
|
|
54 2004-05-27.txt:16:06:48: <fizzie> oh, right, funge98 also includes the "stack stack"
|
|
55 2004-05-27.txt:16:07:05: <fizzie> where instead of a single stack you actually have a stack of stacks, and you can manipulate those.
|
|
56 2004-05-27.txt:16:08:18: <fizzie> (if you're not familiar with forth, it just reaches into the stack and pulls out a number from an arbitrary depth.)
|
|
57 2004-05-27.txt:16:13:24: <fizzie> oh, and another difference: '93 had a defined 8-bit playfield and 32-bit stack. in funge98 the actual amount of bits is implementation-defined, but stack cells and playfield cells will be the same size.
|
|
58 2004-05-27.txt:16:14:27: <fizzie> but you can put anything from the stack to the playfield without having to worry about it being too big.
|
|
59 2004-05-27.txt:16:15:51: <Keymaker> it isn't pretty useful to have 32-bit stack and 8-bit playfield in 93'?
|
|
60 2004-05-27.txt:16:17:16: <fizzie> sorta-makes sense. the playfield is "text", composed of eight-bit octets, and the stack isn't 8-bit to allow you to calculate with larger numbers.
|
|
61 2004-05-27.txt:23:03:11: <lament> oh, fuck logic then :)
|
|
62 2004-05-28.txt:20:51:07: <calamari_> also, I'm not sure how big a stack I'll need
|
|
63 2004-05-31.txt:21:59:52: <fizzie> book's by philip k. dick, who has written lots of excellent books, imho. not about robots though.
|
|
64 2004-06-10.txt:20:17:51: <lament> it would also require a fucking big computer
|
|
65 2004-06-11.txt:20:25:41: <lament> fuck.
|
|
66 2004-06-11.txt:20:34:06: <lament> FUCK
|
|
67 2004-06-15.txt:10:05:56: <calamari_> for those wondering.. I have bfasm working with simple programs. Next I need to do arrays, then the stack, and finally put in text -> memory storage
|
|
68 2004-06-20.txt:18:11:28: <calamari_> I haven't finished implementing the STK command (to set the stack size).. also need to understand/use a few of dbc's compare and divide/mod routines
|
|
69 2004-06-20.txt:18:12:12: <calamari_> stack (accessible via push & pop only)
|
|
70 2004-06-28.txt:02:47:30: <WildHalcyon_> One option is just to push the function name onto the stack and have an 'execute' command
|
|
71 2004-06-28.txt:04:04:01: <Toreun> it has a stack and a queue
|
|
72 2004-06-28.txt:04:09:11: <WildHalcyon> so there's a stack and a queue?
|
|
73 2004-07-02.txt:06:38:15: <heatsink> Can a single datum (a cell, the stack contents, etc.) be arbitrarily big? Because then you could pack the lambda function into a single value, and then unpack it in-place... In fact, I've been wanting to do an esolang sort of like that
|
|
74 2004-07-02.txt:06:39:20: <WildHalcyon> Stack contents possibly, but an actual cell is limited to a 8-bit value
|
|
75 2004-07-06.txt:07:12:00: <WildHalcyon> like regular lambda functions in false - they're pushed onto the stack and executed like normal
|
|
76 2004-07-08.txt:17:04:39: <mtve> there was small tcpip stack in php and it shouldn't be more than 64k of bf-asm code i think.
|
|
77 2004-07-08.txt:17:10:52: <fizzie> there's all kinds of stuff like explicit congestion notification (RFC2884), syncookies, window scaling (RFC1323), Nagle's algorithm and loads of others if you want a funky tcp/ip stack.
|
|
78 2004-07-12.txt:21:02:01: <calamari_> is there an easy way to deal with that (I'm using something similar to recursive descent, using a stack rather than recursive calls)
|
|
79 2004-07-17.txt:22:13:29: <Lord_AnthraX> fuck the 8-ball
|
|
80 2004-08-05.txt:04:41:43: <JoeyP> WHAT THE FUCK REALTIME LOGGIN OMG LOL
|
|
81 2004-08-05.txt:04:46:05: <lament> What the fuck is esper.net?
|
|
82 2004-08-05.txt:04:50:05: <LinkMasterSab> Shit*
|
|
83 2004-08-05.txt:04:56:39: <LinkMasterSab> The two stacks don't interact.
|
|
84 2004-08-05.txt:05:01:25: <JoeyP> shitty++
|
|
85 2004-08-05.txt:15:00:38: <JoeyP> I'll take that as a "NO BITCH, NOW FUCK OFF YOU FUCKING CUNT"
|
|
86 2004-08-12.txt:01:26:05: <JoeyP> oh shit
|
|
87 2004-08-12.txt:01:26:22: <JoeyP> i know, just a stack
|
|
88 2004-08-12.txt:01:26:36: <LinkMasterSab> Stacks are coo <23
|
|
89 2004-08-12.txt:01:27:41: <LinkMasterSab> pop(0) unless the callback stack isn't empty.
|
|
90 2004-08-12.txt:01:30:01: <JoeyP> it will be shitty though
|
|
91 2004-08-12.txt:01:30:27: <LinkMasterSab> Optimizing with large numbers causes it to use stacks you might not want it to :/
|
|
92 2004-08-12.txt:01:30:51: <LinkMasterSab> Plus I couldn't figure out how the fuck to make it work with the stacks to being with.
|
|
93 2004-08-12.txt:01:39:26: <JoeyP> this is shitty
|
|
94 2004-09-14.txt:21:27:53: <ZeroOne> something has to be thought for orphan letters which probably will appear. maybe if a letter set doesn't form an instruction, it could be pushed to stack
|
|
95 2004-09-14.txt:21:36:51: <fizzie> was going to write a befunge variant with "define", "call" and "return" instructions. 'define' would take an (x,y) pair that defines the start of an function and a small integer 'n' which would be the "name", 'call' would pop n and go to the function, but push the return address to stack, and 'return' would pop the return address off the stack and go back.
|
|
96 2004-09-14.txt:21:37:10: <fizzie> not sure if I wanted a separate "execution stack" or to use the normal stack for it.
|
|
97 2004-09-14.txt:21:38:03: <lindi-> separate stack would be too easy
|
|
98 2004-09-14.txt:21:38:19: <fizzie> yes, but if I use the normal stack then delivering parameters to functions will be hard.
|
|
99 2004-11-07.txt:03:35:33: <slava> i'm working on stack effect inference for postfix languages
|
|
100 2004-11-07.txt:03:36:21: <slava> eg, the stack effect of 2 2 + is [ 0 | 1 ] because it takes no values from the stack, but leaves one
|
|
101 2004-11-07.txt:03:36:38: <slava> the stack effect of dup * is [ 1 | 1 ], because it takes one value, duplicates it, multiplies the two duplicates, to yield one value
|
|
102 2004-11-07.txt:03:37:07: <heatsink> Doesn't 2 2 + take two values from the stack and then add one?
|
|
103 2004-11-07.txt:03:37:48: <heatsink> so what is the stack effect of printf?
|
|
104 2004-11-07.txt:03:39:17: <slava> so the stack effect of 2 2 + is [ 0 | 1 ] * [ 0 | 1 ] * [ 2 | 1 ]
|
|
105 2004-11-07.txt:03:40:27: <jDoctor> it should lead to computer-generated stack effects, right?
|
|
106 2004-11-07.txt:03:41:29: <heatsink> do both branches of an if-then-else have to have the same stack effect to be legal?
|
|
107 2004-11-07.txt:03:42:44: <slava> since after the ifte, the stack height is constant, sonce the two branches are balanced
|
|
108 2004-11-07.txt:03:43:54: <slava> this is valid, since i have proofs that balanced sets of stack effects behave just like the maximimal element under pairwise composition
|
|
109 2004-11-07.txt:03:44:26: <slava> words that take variable numbers of arguments off the stack?
|
|
110 2004-11-07.txt:03:51:40: <slava> yes, but I don't infer stack effects of code involving them.
|
|
111 2004-12-26.txt:12:52:04: <nooga_> code space, output window and stack listener :)
|
|
112 2004-12-26.txt:13:55:36: <nooga_> because i dont pop from the stack when | or _ are noticed
|
|
113 2005-01-16.txt:12:07:01: <mtve> _ operator pops the stack
|
|
114 2005-01-16.txt:12:15:59: <Keymaker> will the first in stack be 0 or the one that is followed by "
|
|
115 2005-01-16.txt:12:16:19: <Keymaker> "hi" would there be on stack 0 h i
|
|
116 2005-01-16.txt:12:17:34: <mtve> and most of implementations pop zero from empty stack.
|
|
117 2005-02-05.txt:22:19:15: <arke> and in a loop, you can fuckit all up because you forgot to scroll once!
|
|
118 2005-02-15.txt:16:49:45: <Keymaker> aarrggh. public commander keen forum has been attacked with shit-eating pictures and other grotesque material :(
|
|
119 2005-02-16.txt:22:45:26: <Keymaker> would it be a stack, array etc...
|
|
120 2005-02-25.txt:00:37:24: <Rogue> cool, i like'm cuz languages like C and VB, are fucking annoying
|
|
121 2005-02-25.txt:00:46:02: <Rogue> a lil fuck aroiund thing
|
|
122 2005-02-25.txt:01:47:44: <Rogue> well, all declared variables are set in a linear array into a stack, so each variable can expand easier, you have a variable declared at code block 7,8 would beput in the next available slot on an array
|
|
123 2005-02-25.txt:01:54:19: <Rogue> the variablables that are in the array/stack would be the z axis
|
|
124 2005-02-25.txt:19:41:28: <Keymaker> "16:37:24 <Rogue> cool, i like'm cuz languages like C and VB, are fucking annoying"
|
|
125 2005-02-28.txt:23:32:57: <arke> teh brainfuck is teh fucking with my teh brain
|
|
126 2005-03-05.txt:22:07:57: <cpressey> the horrific part would be the stack management, i think :)
|
|
127 2005-03-06.txt:08:38:07: <calamari> cpressey: esoapi could be made to work with a stack based language as well
|
|
128 2005-03-06.txt:08:42:21: <calamari> If a language doesn't have a current cell.. then they'd use their stack, or whatever.. up to the language implementor
|
|
129 2005-03-16.txt:06:07:49: <Tefad> i'm using a stack for those
|
|
130 2005-03-16.txt:23:42:43: <arke> then I'm gonna change to eliminate all return stack tricks
|
|
131 2005-03-17.txt:00:52:20: <calamari> arke: I did something similar in a previous contest.. first I wrote it in basic, using functions.. then I removed the functions and used gosub, then I removed the gosubs, just using if/goto/stack. then I saw that someone had it to something like 37 bf instructions, and I gave up :)
|
|
132 2005-03-17.txt:00:57:18: <arke> I think the best bet is to use the BF pointer as a stack, in pretty much every situation
|
|
133 2005-03-18.txt:19:28:54: <{^Raven^}> difficult without a stack
|
|
134 2005-03-20.txt:06:53:31: <{^Raven^}> a TCP/IP stack written in BF
|
|
135 2005-03-20.txt:06:53:43: <calamari> you wouldn't need a full stack
|
|
136 2005-03-20.txt:06:57:19: <calamari> if you do go crazy and decide to do it, check out the network stack written for the old 8-bit computers. I think they have one for c64 and another for atari8
|
|
137 2005-04-04.txt:11:26:42: <graue> should using ? on an empty stack be an error, or just a nop?
|
|
138 2005-04-05.txt:15:37:51: <kipple> you can define custom stacks
|
|
139 2005-04-05.txt:15:38:59: <kipple> on the positive side, it will remove the need for the @ stack (which is an abomination) as a language feature
|
|
140 2005-04-05.txt:15:39:50: <Keymaker> will the output be read from @ stack before o stack?
|
|
141 2005-04-05.txt:15:41:28: <kipple> so the next version will add one operator and remove the special stack @
|
|
142 2005-04-05.txt:15:41:49: <Keymaker> and the one operator is that custom stack?
|
|
143 2005-04-05.txt:15:42:37: <kipple> which lets you load custom stacks from a dll/so, a java class or a kipple file
|
|
144 2005-04-05.txt:15:44:53: <Keymaker> by the way, question about the + operator; so, if there are values [8 4 3] in stack b, will the code b+2 cause it to have values [8 4 5] or [8 4 3 5]?
|
|
145 2005-04-05.txt:15:47:04: <Keymaker> and this would be a way to clear that stack: 0>b? , right?
|
|
146 2005-04-05.txt:15:48:49: <Keymaker> so the only way to basically delete one value from stack is to move it to some other stack (and clear that stack where moved if one likes to)
|
|
147 2005-04-05.txt:15:49:54: <kipple> I usually use one of the stacks for this purpose only
|
|
148 2005-04-05.txt:15:50:14: <Keymaker> how big are the stacks?
|
|
149 2005-04-05.txt:15:50:36: <kipple> they are standard java stacks
|
|
150 2005-04-05.txt:15:51:41: <Keymaker> and in empty stack this code a+a would cause the stack have value [ 0 ] ?
|
|
151 2005-04-05.txt:15:52:50: <Keymaker> and a+b have the same [ 0 ] in a stack and nothing in b
|
|
152 2005-04-05.txt:16:18:08: <Keymaker> ah, i just realized that way to dublicate a value in stack is to add zero to it
|
|
153 2005-04-05.txt:19:42:44: <graue> the main idea was to learn C++ by making an interpreter for some stack-based language
|
|
154 2005-04-06.txt:12:05:47: <Keymaker> kipple: what program a-500 should do. let's assume there is for example value [1] in the stack.
|
|
155 2005-04-06.txt:12:19:16: <kipple> then the stack should be [1 -499]
|
|
156 2005-04-14.txt:20:08:15: <Keymaker> "Good shit, huh? Dozer makes it. It's good for two things: degreasing engines and killing brain cells."
|
|
157 2005-04-14.txt:20:23:45: <graue> i wrote some shit there to start it off
|
|
158 2005-04-16.txt:03:20:05: <graue> i tried programming in brainfuck, and it, like, it FUCKED UP MY BRAIN!
|
|
159 2005-04-28.txt:17:36:22: <fizzie> And, as said, creates buggey code. Probably one of my optimization passes. I do some stack-content-analysis to avoid writing conditional jumps that never get taken, and to do constant-folding.
|
|
160 2005-05-04.txt:19:18:03: <GregorR-L> * = all stack and IO operations, + = branch
|
|
161 2005-05-04.txt:19:44:52: <fizzie> BrainFuck (and 2l, apparently) operate on a tape, not a stack. A stack would be a FIFO structure. Other than that, looks like a language I wouldn't want to _have_ to use for some real project. :)
|
|
162 2005-05-04.txt:19:45:37: <pgimeno> a stack would be a LIFO ;)
|
|
163 2005-05-04.txt:19:50:54: <GregorR-L> Just changed stack to tape and operation to symbol
|
|
164 2005-05-04.txt:20:04:30: <fizzie> I think the befungey parts of blank are its stack-basedness, plus the instruction set is befunge-inspired. The program sits in a one-dimensional ring, however.
|
|
165 2005-05-05.txt:13:12:30: <pgimeno> anyway stack-based languages are not among my favorites
|
|
166 2005-05-05.txt:13:13:07: <Keymaker> i'm not such fan of stacks, probably because i have never used them before esolangs
|
|
167 2005-05-05.txt:13:13:39: <pgimeno> that's probably why I don't like stacks
|
|
168 2005-05-06.txt:13:17:26: <Keymaker> the quine works the way that first it reads it own instructions to stack (stuff inside " ")
|
|
169 2005-05-06.txt:13:17:53: <Keymaker> the instructions tell it to print out '"'s and the stuff there is in stack
|
|
170 2005-05-08.txt:18:45:49: <Keymaker> i'm not sure if the place allows to use 'fuck' in the domain name
|
|
171 2005-05-09.txt:23:50:27: <kipple> difficult handling multiple stacks in such a language I would think
|
|
172 2005-05-10.txt:04:34:53: <Keymaker> GregorG: by its stacks?
|
|
173 2005-05-10.txt:04:42:35: <Keymaker> but not that much, just remember that stack names are one character (a..z or @)
|
|
174 2005-05-10.txt:04:47:33: <Keymaker> as well remember that a stack can be "connected" with two stuff like a>b<499
|
|
175 2005-05-10.txt:17:07:47: <kipple> the stacks are 1 dimentional, but since there are several stacks one could perhaps argue that it is 2D?
|
|
176 2005-05-10.txt:17:56:21: <GregorR-L> Mainly, do I want the data pointer to just be in a stack or tape...
|
|
177 2005-05-11.txt:05:24:47: <GregorR> If you stack two +s, they can't be pushed
|
|
178 2005-05-12.txt:01:13:32: <kipple> so how do you manage to do stacks?
|
|
179 2005-05-12.txt:01:14:20: <GregorR-L> But their design happens to be particularly condusive to stacks.
|
|
180 2005-05-12.txt:01:17:27: <kipple> There is such a thing as a stack item.
|
|
181 2005-05-12.txt:01:17:28: <kipple> A stack item has an item below which is a stack item.
|
|
182 2005-05-12.txt:01:17:28: <kipple> A stack item has an item on top which is a stack item.
|
|
183 2005-05-12.txt:19:16:43: <GregorR-L> A 2D programming language where you draw a stack, then physically move data above it and drop it in :-P
|
|
184 2005-05-12.txt:19:16:59: <GregorR-L> So you have to navigate your program pointer above the stack, then do a "drop" operation
|
|
185 2005-05-12.txt:20:20:34: <Keymaker> GregorR: nice idea about that 2D language where you actually need to collect stuff from the stack
|
|
186 2005-05-13.txt:09:13:19: <lament> no shit
|
|
187 2005-05-13.txt:23:52:27: * pgimeno prefers fuck rather than dead
|
|
188 2005-05-14.txt:08:06:36: <GregorR> I can read in a kipple file and figure out what's a number, what's a stack, what's an operation, and organize it as such.
|
|
189 2005-05-18.txt:23:20:59: <kipple> btw, the @ stack will probably be gone in the next version... :D
|
|
190 2005-05-19.txt:00:21:49: <kipple> no it duplicates the top value on the stack
|
|
191 2005-05-19.txt:00:26:07: <kipple> public void execute() throws StackException {
|
|
192 2005-05-19.txt:00:53:54: <kipple> the @ stack works a bit differently, but otherwise it seems to work fine :)
|
|
193 2005-05-19.txt:19:24:55: <kipple> and the @ stack pads up to six (i think) zeroes
|
|
194 2005-05-21.txt:00:58:31: -!- wooby has quit ("[BX] Were you born a fat, slimy, scumbag, puke, piece of shit or did you have to work on it?").
|
|
195 2005-05-27.txt:01:13:02: <malaprop> kipple: Well, if you're volunteering to write the TCP/IP stack...
|
|
196 2005-05-27.txt:01:19:12: <GregorR> The stack begot a register.
|
|
197 2005-05-27.txt:14:26:53: <jix> with a 3rd binary stack instructions it is turing complete (because i know how to implement a BF interpreter)
|
|
198 2005-05-27.txt:23:31:24: <kipple> well, the next version of Kipple will allow code modules, so then you can write a division stack once, and then reuse it...
|
|
199 2005-05-28.txt:00:38:44: <jix> i'm not using the input stack as a temp stack
|
|
200 2005-05-28.txt:00:58:18: <kipple> btw, there is NOTHING wrong with using the input stack as a temp stack!
|
|
201 2005-05-28.txt:22:18:53: <jix> i'm going to parse the code into a struct-structure and than execute it.. the stack functions/structures are done..
|
|
202 2005-05-28.txt:22:49:45: <jix> using the stack _ poping it is reading a char and pushing it is writing a char
|
|
203 2005-05-28.txt:22:51:08: <kipple> the next version of the language has the ability to load customized stacks, so then you could do that
|
|
204 2005-05-28.txt:22:59:21: <kipple> ah, because of stack limitations?
|
|
205 2005-05-28.txt:23:41:26: <kipple> handling the 26 different stacks in BF would be a nightmare IMHO, but good luck!
|
|
206 2005-05-28.txt:23:46:06: <Keymaker> harder than the stacks would be the big numbers, i guess
|
|
207 2005-05-29.txt:12:41:47: <jix> hmm.. is it possible to implement the @ stack in kipple
|
|
208 2005-05-29.txt:12:42:31: <jix> i push a number, read from the stack, push a number, read from the stack
|
|
209 2005-05-29.txt:12:45:26: <kipple> a stack that adds 1 to all pushed values?
|
|
210 2005-05-29.txt:12:45:50: <kipple> well it can't be named a (a-z are reserved for normal stacks)
|
|
211 2005-05-29.txt:12:48:52: <jix> hmm.. for the @ stack every push would be optimal.. but if one would like to have the opposite of @ every pop would be better
|
|
212 2005-05-29.txt:12:49:25: <kipple> currently a push sets the "evaluate" flag. On a pop the code is executed if the flag is set. then the topmost value of the custom stack's o is popped
|
|
213 2005-05-29.txt:13:08:23: <jix> yes because adding a value and adding a value popped from a stack are two different things
|
|
214 2005-05-29.txt:13:12:12: <jix> but my interpreter is written for speed and it's faster if it knows if it has to add a value stored in the program or stored in a stack
|
|
215 2005-05-29.txt:13:13:42: <jix> i think i still have to finetune the values for reallocating the stack memory
|
|
216 2005-05-29.txt:13:22:21: <jix> "a<12" check 'a' is 'a' an instruction ? no.. next char: '<' .. instruction! it needs a stack on the left site.. ok end on the right site is.. a number so seek until the end of the string OR to a nonnumber char
|
|
217 2005-05-29.txt:13:28:20: <jix> hmm.. one for every stack .. and one for every instruction
|
|
218 2005-05-29.txt:13:28:48: <jix> but i inline the stack methods !
|
|
219 2005-05-29.txt:13:28:51: <kipple> I have one object for every stack, instruction and operand (including numbers)
|
|
220 2005-05-29.txt:13:29:57: <jix> union { stack* s; int i;} op_a;
|
|
221 2005-05-29.txt:13:30:20: <jix> for stack and int.. op_b has also an p for a sub program (looping)
|
|
222 2005-05-29.txt:15:00:35: <jix> but the @ stack doesn't work
|
|
223 2005-05-31.txt:01:23:08: <kipple> I think it is the sub-recipes that's the problem. Each sub-recipe call results in all the stacks being copied every time
|
|
224 2005-05-31.txt:15:31:41: <Keymaker> so it would finally have 1 1 1 in b stack?
|
|
225 2005-05-31.txt:15:32:00: <kipple> no it would have 1 1 1 1 in the b stack
|
|
226 2005-05-31.txt:16:06:08: <kipple> all input is pushed onto the i stack BEFORE the program is executed
|
|
227 2005-05-31.txt:16:08:16: <pgimeno> whenever a program tries to use the input stack for the first time, the input will be read
|
|
228 2005-05-31.txt:16:09:11: <kipple> the problem is that the input stack might be used for other purposes (it is not exclusively for input)
|
|
229 2005-05-31.txt:16:11:04: <pgimeno> kipple: imagine that you keep a count of elements on the 'i' stack
|
|
230 2005-05-31.txt:16:11:38: <malaprop> it's be weird for the interpreter to pause for input when code tries to push onto the input stack.
|
|
231 2005-05-31.txt:16:13:15: <kipple> as it is now it is perfectly legal to pop from an empty stack (will return 0). so you can easily check if the program has recieved any input. this will not work if a pop will result in a getchar()
|
|
232 2005-05-31.txt:16:15:51: <pgimeno> if you pop from the 'i' stack and there's input, you don't receive a 0
|
|
233 2005-05-31.txt:16:16:36: <graue> why would the interpreter have to pause for input when code pushes on the input stack?
|
|
234 2005-05-31.txt:16:16:38: <pgimeno> similarly, if you pop from the 'i' stack in 'lazy input' mode, then all input is gathered and pushed and you don't receive a 0 either
|
|
235 2005-05-31.txt:16:16:50: <kipple> as far as I understood your solution, if you pop the i stack and it's empty, then you would trigger a getchar(), no?
|
|
236 2005-05-31.txt:16:19:44: <kipple> the difference being that you cannot pop the i stack, and find out if any input was passed to the program, because that would trigger input to be read
|
|
237 2005-05-31.txt:16:24:12: <kipple> consider the following program: it checks to see if there is any input by popping the i stack, and checking for 0. if 0 then print "please provide input!" and terminates. else it performs some operations on the input
|
|
238 2005-05-31.txt:16:25:31: <malaprop> print "please provide inpurt: ", pop input stack
|
|
239 2005-05-31.txt:16:29:04: <pgimeno> kipple: in other words, it's the implementation of the pop operation the one which reads the input: if the instruction is a pop, and the stack is 'i', and the number of elements is 0, then read the input (if any) and return the first byte (or 0 if none); otherwise perform as any other stack pop
|
|
240 2005-05-31.txt:16:30:08: <malaprop> pgimeno: And, if stack is empty and no input is given, the stack stays empty and future calls don't try to get input.
|
|
241 2005-05-31.txt:16:31:05: <pgimeno> and if it's used as any other stack but it never is popped when empty, no input will be read
|
|
242 2005-05-31.txt:16:45:24: <graue> how many stacks does a language need to be Turing-complete?
|
|
243 2005-05-31.txt:16:47:18: <graue> so a single deque would be enough, since it can be treated as two stacks, right?
|
|
244 2005-05-31.txt:16:49:13: <fizzie> According to some googling there is a working representation of two stacks in a single queue.
|
|
245 2005-05-31.txt:17:28:31: <Keymaker2> "According to some googling there is a working representation of two stacks in a single queue."
|
|
246 2005-05-31.txt:17:30:41: <fizzie> Well, http://jackson.cs.miami.edu/~burt/papers/1993.1/Saq-JAIIO-2.ps has a proof of the queue-automata-is-equivalent-to-turing-machine thing, but it doesn't (unless I misread, I just briefly looked at it) use two-stacks-in-a-queue, that one was a CS assignment or something.
|
|
247 2005-05-31.txt:18:01:14: <kipple> the problem is the copying of ALL the stacks each time a sous chef is called
|
|
248 2005-05-31.txt:22:05:56: <kipple> quoted from 99-bottles-of-beer.net: "What the fuck is going on here? In fact we got two Chef submissons within a couple of hours. As soon as I have some time on my hands, I will add support for showing several examples for each language cuz I don't want to be the one who decides which is the better one etc. For now I activated the first submission." :D
|
|
249 2005-06-01.txt:23:52:20: <graue> a literal number or string just pushes itself onto the stack
|
|
250 2005-06-01.txt:23:52:36: <pgimeno> I missed the stack part
|
|
251 2005-06-02.txt:04:36:03: <GregorR> So, stack elements are a sort of "variant," that can be either a number or a string?
|
|
252 2005-06-02.txt:04:49:11: <graue> an expression that is evaluated must result in exactly one value on the stack
|
|
253 2005-06-02.txt:21:20:10: <cpressey> or... no, even befunge has a stack, making it a PDA
|
|
254 2005-06-03.txt:16:34:26: <sp3tt> Basically uses a stack to print Hello world, when it can be done without one. Also demonstrates how to use userdefined vars in functions.
|
|
255 2005-06-04.txt:12:41:17: <kipple> graue: I've read the Sortle spec. it's not clear to me how to push values onto the stack.
|
|
256 2005-06-04.txt:12:41:50: <kipple> there are a list of operators that work on the stack, but I can't find how to acutally get any data on the stack in the first place...
|
|
257 2005-06-04.txt:13:10:01: <graue> kipple, literal numbers or strings push themselves onto the stack
|
|
258 2005-06-04.txt:13:11:38: <kipple> ok. so will the expression "12" push 12 or 1 and 2 onto the stack?
|
|
259 2005-06-04.txt:13:46:09: <kipple> i assume my interpreter will give an invalid stack identifier error or something
|
|
260 2005-06-04.txt:13:48:57: <kipple> hmm. here's a thought: If I allow < to be used as a stack name, then this expression could be used: a<<b (a.push(<.pop()); <.push(b.pop()) )
|
|
261 2005-06-04.txt:13:51:41: <kipple> hmm. I think I will allow ANY character as a stack name in the next version, except numbers, whitespace and #
|
|
262 2005-06-04.txt:14:07:33: <jix> no a stack
|
|
263 2005-06-04.txt:14:07:49: <kipple> it's either a stack or an operator
|
|
264 2005-06-04.txt:14:19:26: <kipple> hmm. should I keep stack names case insensitive, or change to case sensitive?
|
|
265 2005-06-04.txt:17:42:19: <kipple> "k">( would give an error that ( is not a stack
|
|
266 2005-06-04.txt:19:02:18: <GregorR> My peptide chains will stack rather than fold, and simply based on every-other amino acid being "compatible"
|
|
267 2005-06-04.txt:19:50:02: <kipple> isn't fuckfuck one of those as well?
|
|
268 2005-06-04.txt:19:53:03: <kipple> I think we should aim to include every esolang, even ook, fuckfuck, cow etc. but those could be bunched together in one article, referenced from the BF article
|
|
269 2005-06-04.txt:20:13:07: <kipple> for instance: I think we should have a "stack-based" category
|
|
270 2005-06-04.txt:20:13:46: <CXI> stack-based meaning which languages?
|
|
271 2005-06-04.txt:20:14:00: <kipple> but what exactly is that? only langs with only one stack, like befunge, or including languages like Chef and Kipple?
|
|
272 2005-06-04.txt:20:14:36: <pgimeno> I think that including all; that makes it easier to look for a particular language which is stack based
|
|
273 2005-06-04.txt:20:15:01: <jix> languages that use stacks as its main/only data structure
|
|
274 2005-06-04.txt:20:19:32: <sp3tt> FuckYorBrane XD
|
|
275 2005-06-04.txt:21:41:38: <lament> but shit
|
|
276 2005-06-04.txt:21:55:33: <sp3tt> The program should output "Your brain is fucked" XD
|
|
277 2005-06-04.txt:22:06:38: <fizzie> I seem to recall some pushdown-automata-like language (single stack, no other real storage), but now I've forgotten it. How is befunge classified, btw? At least '93 has that 80x25 fixed size limit...
|
|
278 2005-06-04.txt:22:08:23: <lament> fuck.
|
|
279 2005-06-04.txt:22:48:11: <sp3tt> Ok, Brainfuck totally rocks, pwns, and is teh shit!
|
|
280 2005-06-04.txt:22:52:53: <sp3tt> That prints "Your brain is fucked!"
|
|
281 2005-06-04.txt:23:13:41: <sp3tt> And the text is a brainfuck program that outputs "Your brain is fucked".
|
|
282 2005-06-05.txt:00:46:53: <jix> auto converted (BF=>BOOF=>XUML) programs are going to be so fucked long
|
|
283 2005-06-05.txt:17:59:49: <sp3tt> It prints "Your brain is fucked!"
|
|
284 2005-06-05.txt:20:48:31: <graue> it seemed unclear what was or wasn't by reference, "deep copies" and "shallow copies" left my brain all fucked, so i stopped working on it
|
|
285 2005-06-05.txt:20:56:49: <sp3tt> graue: you mean python fucked up your brain less that bf?
|
|
286 2005-06-06.txt:10:06:32: <lament> a stack...
|
|
287 2005-06-07.txt:22:19:55: <lament> each line controls a separate stack
|
|
288 2005-06-07.txt:22:20:21: <lament> instructions < and > access data from neighD[D[D[D[D[D[Dbouring stacks
|
|
289 2005-06-07.txt:22:21:19: <graue> so the stacks run in parallel?
|
|
290 2005-06-07.txt:22:21:48: <lament> < gets data from the stack above (with wraparound)
|
|
291 2005-06-07.txt:22:21:56: <lament> > gets data from the stack below (with wraparound)
|
|
292 2005-06-07.txt:22:22:23: <lament> will add to both stacks the top value on the other swap
|
|
293 2005-06-07.txt:22:22:26: <lament> *other stack
|
|
294 2005-06-07.txt:22:25:42: <lament> (without the use of a third stack)
|
|
295 2005-06-07.txt:22:27:24: <lament> even with the third stack it's not trivial :(
|
|
296 2005-06-07.txt:22:28:03: <lament> with the use of the third stack, swapping values in the first two:
|
|
297 2005-06-07.txt:22:37:32: <lament> because you're not limited to two stacks
|
|
298 2005-06-07.txt:22:43:57: <kipple> when you say "# drop last value", you mean the top of the stack, right?
|
|
299 2005-06-07.txt:22:50:39: <kipple> does the ^ and v alter the stack above/below ,or just peek at it?
|
|
300 2005-06-07.txt:23:23:24: <lament> the bottom stack keeps growing?
|
|
301 [too many lines; stopping]
|