World: r3wp
[All] except covered in other channels
older newer | first last |
Maxim 7-Jan-2009 [3243] | guess who's the belgian ;-) |
xavier 7-Jan-2009 [3244] | i dont want to be considered as alcoolic, beer is a part of the culture of a country .... i love culture |
Maxim 7-Jan-2009 [3245] | ;-) |
xavier 7-Jan-2009 [3246] | i ll be very glad to meet you btifin :) |
btiffin 7-Jan-2009 [3247] | Well if you do, it'll be at Ottawa's coolest punk bar. A real dive with an awesome vibe. And pool tables. ;) |
xavier 7-Jan-2009 [3248] | yeah ! |
Maxim 7-Jan-2009 [3249x2] | There are bars in Ottawa? I thought we'd have to cross the river and go to Quebec for that ;-) |
Last time I went to Ottawa, we ran around for one hour in a car, trying to find a street with more than one bar ... didn't find any! ;-) | |
btiffin 7-Jan-2009 [3251] | Then you missed the Byward Market. Tons. Punk, Sport, Dance, Gay, we got 'em. |
Maxim 7-Jan-2009 [3252] | guess so! but in any case I was just joking... you know of people from quebec like Ottawa ;-) |
BrianH 7-Jan-2009 [3253] | Sounds like fun :) |
btiffin 7-Jan-2009 [3254] | Though since they closed the Horse Shoe I don't think there are any "skank ho's be here" bars. Just walking passed the place, you could feel that "vibe" oozing out into the street. ;) |
Maxim 7-Jan-2009 [3255] | hehehe |
btiffin 7-Jan-2009 [3256x2] | Feel? more like smell. ;) |
But yeah, the market definitely is the spot. They pretty much shutdown the nightlife over in Hull, oh 10ish+ years ago. They had roving six packs of cops with shotguns for about a year. Effectively shut it right down. | |
xavier 7-Jan-2009 [3258x2] | :( |
no more nite life in ottawa ? | |
Maxim 7-Jan-2009 [3260] | no he means no more nite life in Hull |
btiffin 7-Jan-2009 [3261] | Then Ottawa had to scramble to change by-laws. The Hull owners wanted to move all the 5,000 seat bars to the Ottawa side. So there is a moratorium until they get it figured out. ;) |
Maxim 7-Jan-2009 [3262] | why did they want to close the partying? gotten too wild, or was it a result of ottawans, crossing the river every night? |
btiffin 7-Jan-2009 [3263x2] | Yeah, xavier, back in the day there was 1am close in Ontario, 3am in Hull Quebec; A mass exodus across the brige started at about midnight. It was fun, but it WAS chaos and it WAS a problem. Now Ontario has 2am close, so things settled a bit. |
Plus QC has 18 age of majority, Ontarion 19, so that added to the fire. ;) | |
xavier 7-Jan-2009 [3265] | 2 am is just the good hour to start to party :) |
Maxim 7-Jan-2009 [3266x2] | its 19 in Ontario! I didn't know about that! |
now you know who who is the belgian ;-) | |
btiffin 7-Jan-2009 [3268x2] | I noticed that when I went to visit friends in Sherbrooke. 10 o'clock and I'm pacing about, "let's go". Little did I know. :) |
Oops, we should be in Chat ... didn't notice. | |
Steeve 7-Jan-2009 [3270] | fortunalty, we don't have such prohibition in France |
xavier 7-Jan-2009 [3271x2] | neither in belgium |
at least u can party all nite | |
Steeve 7-Jan-2009 [3273] | we have a little more advanced culture, they are so young those americans |
xavier 7-Jan-2009 [3274] | in montreal they are pretty advanced ... :) |
btiffin 7-Jan-2009 [3275] | moved to Chat; we're kinda polluting the All group. |
Sunanda 8-Jan-2009 [3276] | Carl asked how many messages here, and guessed 100,000 I see just on 181,000. Your numbers will vary -- it depends on the private groups you are a member of. Plus we each member-to-member messages. They are not counted in my 181,000 |
Gabriele 8-Jan-2009 [3277] | Ok, Brian, now on your above function, try to parse this: "12.3.2.2.2.2[.3.4 5 6 7] 8 9" |
btiffin 8-Jan-2009 [3278] | Gabriele; don't use that loadall, it's broken - badly broken. Chris Ross-Gill posted a link to a much better load-junk, but his version does weird things with "$10,000,000.00" and still doesn't handle the recursion required by a real REBOL load. In defense of us both, they were quick jobs posted only as examples. I'm still unclear why the addition of foreign! data would break REBOL. I'm of the opinion it would increase REBOL usabilty, by an order of magnitude for people not programmers by nature, and open up entirely new fields of endeavour, not make it impossible for professionals to write awesome, concise code as they do today. But ... as you can see from that hack job of loadall, I'll defer to gurus. |
Gabriele 9-Jan-2009 [3279x2] | I'll defer to gurus - that's my point, gurus are telling you that this is a very bad idea... |
so, either you know something we don't, and then you're the only one that can implement this, or we know something you don't :) | |
Pekr 9-Jan-2009 [3281x2] | Gabriele - and if the latter is true, then Gurus should explain to normal mortals, why it is not easily possible and what consequences would proposed solution bring :-) |
But - BrianH already explained that ... | |
Gabriele 9-Jan-2009 [3283x2] | again, the reason is that it is impossible to come up with a general solution, and that this is a UI issue and NOT a language issue. unless you throw in AI, "language" for a computer cannot be the same as "language" for a human. |
so, either we have AI, and the computer can figure out what a human means when reading the text the human wrote (but it'll have to ask questions most of the times! like when a human is talking to another human), or it can only be a specilized thing (eg. a date field that tries to be "smart" - but that's just a big set of rules) | |
Pekr 9-Jan-2009 [3285] | I think that your answer is too abstract :-) All that guys wanted was - any known rebol datatype should be recognised, and the rest should be assigned under junk! or similiarly named datatype. What is AI about that? :-) |
sqlab 9-Jan-2009 [3286x2] | load-all: func [ s [string!] /with limit [string!] ] [ s: either with [ parse/all s limit ] [ parse s none ] forall s [ s/1: any [ attempt [load s/1] ] [ s/1 ] ] s ] But you have to decide, what you wish as a delimiter or as part of item. |
there was a bug load-all: func [ s [string!] /with limit [string!] ] [ s: either with [ parse/all s limit ] [ parse s none ] forall s [ s/1: any [ attempt [load s/1] s/1 ] ] s ] | |
btiffin 9-Jan-2009 [3288] | Gabriele; no sorry; I guess I obfuscated my point too much with the money! example. I don't want REBOL to figure out all the possible human combinations of money. I want REBOL to load a value that we humans commonly use as a format of money, without a syntax error. The make phase would create a foreign data value and keep going. Let the gurus that write general applications worry about the math operations on junk and account for it. But let a professor load his book and use the uber powerful series operations of REBOL for ad hoc analysis. No AI involved here, just a feature of the language that "if a piece of source does not match one of the lexically strict 57 datatypes, it floats in a REBOL block as foreign". And foreign is similar but not quite exactly the same as quoting the text as string!, without need of quoting the text. I see great power in this feature. Excuse the poor example; I misdirected my intention when I mentioned that arg1 had a good hint, my mistake (but I would if I had brains, include this hint as a subfield of foreign! data, just because, why not, the current lexical parser already made a guess). Our good Mr Hawley has a plan for a LOAD refinement /else with a type spec that looks very promising, but then it leads to being able to distinguish actual quoted input from coerced input, so I still lean toward foreign. My plan (and I place burden of foreign! management for CODE blocks to the gurus) would let normal people load any data and run with it. Even it they only use 4 or 5 REBOL functions at the console, the potential userbase becomes orders of magnitude greater than what we have today. That it turn opens up a few that will write concise clear time lasting code that could analyze books or the sum of human knowledge using our favourite thinking environment. No? |
Maxim 9-Jan-2009 [3289] | for me the key point lies not in the fact that we can already make mezz func which simulates the foreign! handling with a function such as ASSIMILATE. the difference lies in the fact that if the native function can load invalid data, then it should simply because of the the fantastical speed its able to convert string data into rebol literal values of a variety of types. hooking up interpreter driven code within the handling of that will slow it down. using the parse with next refinement works... but its nowhere near as fast, for loading, say 300MB of scientific data. which is an actual case I had to deal with. just doing a replace/all on that file took 30Minutes. assimilate with foreign! handling would have taken about 5-10 seconds, and the code would have also been easier to write over all. |
Dockimbel 9-Jan-2009 [3290] | Brian and Pekr, you can easily define where your foreign! value (garbage) would start, but you cannot define in a *general* way where it should end. You can only define that on specific cases and with specific rules. That's Gabriele's point. For example, let's see how an invalid input could be parsed using a theoretical foreign! type (represented below as quoted string for easier reading). Test input string to parse: "123 abc 4c5.6" Possible alternative outputs from a relaxed LOAD: [123 abc "4c5.6"] [123 abc 4 "c5.6"] [123 abc 4 c5.6] [123 abc 4 c 5.6] [123 abc "4c" 5.6] ... Question: which one is the correct output that LOAD should produce? Answer: you can't know until you ask me what I wanted to express. You cannot expect from LOAD to know how to handle invalid data (and to determine where it ends), the best thing LOAD can do is to stop on syntax error. If you have hints or rules on how should foreign be parsed, then write some parse rules and use string! parsing. LOAD/else is a nice REP, but again it can only work on specific data. You cannot feed it with *any* data and expect it to work. |
Maxim 9-Jan-2009 [3291x2] | usuall rebol separators is the ovbious reply... spaces. we all agree that we don't expect the system to behave magically. |
for my part I just know how many times, this would have simplified parsing of mechanically generated data. | |
older newer | first last |