Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #29282 > unrolled thread
| Started by | Jason Damisch <jasondamisch@yahoo.com> |
|---|---|
| First post | 2014-04-04 10:26 -0700 |
| Last post | 2014-04-29 22:52 -0700 |
| Articles | 20 on this page of 374 — 32 participants |
Back to article view | Back to comp.lang.forth
Epic Fail Jason Damisch <jasondamisch@yahoo.com> - 2014-04-04 10:26 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-04 12:42 -0500
Re: Epic Fail forthisit@gmail.com - 2014-04-04 11:09 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-04 22:09 +0100
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-04 21:44 -1000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-05 09:42 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-05 10:47 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-05 15:25 -0400
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-07 17:29 +0000
Re: Epic Fail Assad Ebrahim <assadebrahim2000@gmail.com> - 2014-04-07 12:35 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-08 15:54 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-08 12:43 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-09 16:16 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-09 13:00 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-09 21:08 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-09 15:17 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-10 00:17 +0200
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-09 22:42 -0700
Re: Epic Fail Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-04-10 00:06 -0700
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-10 16:00 +0100
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-10 22:35 +0200
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-10 17:51 -0700
Re: Epic Fail Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-04-10 21:44 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-11 23:10 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-12 06:18 -0400
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-12 06:23 -0400
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-12 10:52 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.invalid> - 2014-04-12 20:14 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-12 19:21 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-13 12:25 -0500
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-13 20:33 -0400
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-12 16:12 +0000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-12 09:48 -0700
Re: Epic Fail Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-04-12 10:23 -0700
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-12 19:51 +0000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-12 13:00 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-12 10:29 -0700
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-12 19:56 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 00:25 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-13 10:50 +0100
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 16:53 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.invalid> - 2014-04-14 02:32 +0200
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 17:59 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-14 02:00 +0100
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 18:30 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-13 14:21 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 21:12 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-23 12:49 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-28 21:02 -0700
Automatic scoping of locals (was: Epic Fail) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-29 14:49 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-10 03:04 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-11 17:23 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-11 21:42 +0200
Re: Epic Fail Spam@ControlQ.com - 2014-04-11 16:13 -0400
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-11 22:15 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-13 16:10 +0000
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-13 18:42 +0100
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-13 23:44 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-13 20:33 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-14 04:05 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-14 09:57 +0000
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-14 11:56 +0100
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-14 14:53 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-14 07:26 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-14 21:21 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-15 04:07 -0500
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-14 09:55 -0700
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-14 22:04 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-15 04:10 -0400
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-15 02:40 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-15 06:41 -0400
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-15 06:20 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-15 12:21 +0000
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-15 06:30 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-15 20:04 -0700
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-15 23:50 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-15 21:31 -1000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-16 05:55 -0700
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-16 14:50 +0100
Re: Epic Fail Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-16 06:06 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-19 17:44 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-20 11:35 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-16 00:19 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-16 05:29 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-16 22:45 -0400
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-14 09:49 +0000
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-23 13:07 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-23 20:16 -0400
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-23 14:41 -1000
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-24 17:10 +0000
Re: Epic Fail Spam@ControlQ.com - 2014-04-24 15:14 -0400
@ and optimization (was: Epic Fail) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 08:40 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-25 06:13 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 15:26 +0000
Re: @ and optimization Paul Rubin <no.email@nospam.invalid> - 2014-04-25 09:03 -0700
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 17:45 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-25 11:15 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 17:22 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 04:38 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 11:38 +0000
Re: @ and optimization Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-26 14:35 +0200
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 09:59 -0500
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 10:14 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 15:30 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 12:05 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 17:27 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 12:39 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 18:07 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-27 03:24 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-27 13:00 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-27 11:18 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-28 15:12 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-29 03:52 -0500
Re: @ and optimization Mark Wills <markwills1970@gmail.com> - 2014-04-29 03:09 -0700
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-29 09:24 -0500
Re: @ and optimization "Elizabeth D. Rather" <erather@forth.com> - 2014-04-29 08:36 -1000
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-29 14:38 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-29 10:21 -0500
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-29 15:41 +0000
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-29 12:26 -0500
Re: @ and optimization Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-29 20:17 +0200
Re: @ and optimization stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-29 19:21 +0000
Re: @ and optimization Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-29 23:20 +0200
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-30 03:02 -0500
Re: @ and optimization Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-26 20:55 +0200
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-27 03:28 -0500
Re: @ and optimization albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-27 13:31 +0000
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-28 15:27 +0000
Re: @ and optimization albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-27 13:23 +0000
Re: @ and optimization hughaguilar96@yahoo.com - 2014-04-28 21:32 -0700
Re: @ and optimization "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 08:50 -0400
Re: @ and optimization "Alex McDonald" <blog@rivadpm.com> - 2014-04-26 22:52 +0100
Re: @ and optimization "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 20:33 -0400
Re: @ and optimization "Alex McDonald" <blog@rivadpm.com> - 2014-04-27 11:53 +0100
Re: @ and optimization "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-28 01:05 -0400
Re: @ and optimization Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-25 21:34 +0100
Re: @ and optimization Paul Rubin <no.email@nospam.invalid> - 2014-04-25 13:37 -0700
Re: @ and optimization Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-25 22:03 +0100
Re: @ and optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 15:38 +0000
Re: @ and optimization Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 17:24 +0100
Re: @ and optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 04:48 -0500
Re: @ and optimization Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 11:09 +0100
Re: @ and optimization (was: Epic Fail) hughaguilar96@yahoo.com - 2014-04-28 21:24 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-24 19:17 +0000
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-25 08:27 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-25 23:44 +0200
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-26 14:37 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-13 15:04 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 09:58 +0100
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 10:16 +0100
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 05:06 -0500
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 11:16 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-26 03:43 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 14:24 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 23:58 -0400
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-27 12:46 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-28 00:41 -0400
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-28 21:54 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 17:17 +0100
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 10:08 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-26 13:44 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 09:11 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 10:12 -0500
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 17:00 +0100
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 12:08 -0500
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-26 23:41 -0400
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 17:06 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-26 12:45 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-26 17:52 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-26 21:52 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-27 03:31 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-27 13:48 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-27 12:02 +0000
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-26 22:19 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-14 10:28 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-14 22:02 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-14 18:57 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-15 05:05 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-14 22:53 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-13 12:34 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-14 13:22 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-14 10:08 -0500
Re: Epic Fail Spam@ControlQ.com - 2014-04-14 11:59 -0400
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-17 16:56 +0000
Re: Epic Fail Spam@ControlQ.com - 2014-04-17 15:16 -0400
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-17 23:59 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-18 04:38 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-18 09:17 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-18 11:44 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-18 17:06 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-18 11:41 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-18 16:55 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-18 19:20 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-20 14:52 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-18 12:21 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-20 14:36 +0000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-20 08:17 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-20 11:35 -0500
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-21 10:51 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-21 19:54 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-22 17:40 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-22 20:47 +0200
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-19 11:34 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-19 16:05 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-20 12:38 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-20 11:42 -0500
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-20 12:11 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-20 17:23 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-20 11:58 -0700
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-21 10:21 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-22 04:58 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-22 17:05 +0000
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-20 17:12 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-20 19:47 -0400
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-22 05:03 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-22 11:51 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-22 08:28 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-22 15:02 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-22 13:23 -0500
Re: Epic Fail Melzzzzz <mel@zzzzz.invalid> - 2014-04-22 19:19 +0200
Re: Epic Fail Todd Hughes <noemail@dontemailme.org> - 2014-04-10 11:24 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-10 06:55 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-10 15:50 +0000
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-10 11:02 -0500
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-10 22:31 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-11 03:55 -0500
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-10 19:08 -0400
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-10 19:03 -0400
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-11 17:45 +0100
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-11 17:16 +0000
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-11 18:59 +0100
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-11 19:11 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-11 12:05 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-11 22:03 -0400
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-11 20:18 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-11 21:44 -0400
Re: Epic Fail visualforth@rocketmail.com - 2014-04-11 14:00 -0700
Re: Epic Fail Matthias Trute <matthias.trute@gmail.com> - 2014-04-12 01:04 -0700
Re: Epic Fail the_gavino_himself <visphatesjava@gmail.com> - 2014-04-09 16:12 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-04 23:20 +0200
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-07 17:40 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-08 00:52 +0200
Re: Epic Fail Assad Ebrahim <assadebrahim2000@gmail.com> - 2014-04-07 16:13 -0700
Re: Epic Fail Ron Aaron <rambamist@gmail.com> - 2014-04-08 06:37 +0300
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-09 01:12 +0200
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-08 10:16 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-04 17:41 -0400
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-05 02:49 +0200
Re: Epic Fail Hannu Vuolasaho <vuokkosetae@gmail.com> - 2014-04-04 17:46 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-04 21:59 -1000
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-05 08:51 +0000
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-05 14:45 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-05 16:01 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-05 19:22 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-06 10:46 +0100
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-06 13:20 +0200
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-06 19:58 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 12:28 -0700
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-06 16:40 -0400
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-06 22:04 +0100
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-06 23:25 +0200
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-06 23:48 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 15:17 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 00:08 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 15:34 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 00:29 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 16:01 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 00:58 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 16:29 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 01:33 +0200
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 01:58 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 19:33 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 04:40 +0200
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 04:25 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 20:19 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 11:23 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 03:24 -0500
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 11:18 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 05:20 -0500
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 14:49 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 08:43 -0500
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-07 20:27 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 02:57 -0500
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-07 10:00 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 16:10 +0200
Re: Epic Fail m.a.m.hendrix@tue.nl - 2014-04-07 07:54 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 22:59 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-07 15:07 -0700
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-07 15:13 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-08 00:40 +0200
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-07 01:02 +0100
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 10:49 -0700
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-08 19:01 +0100
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-08 08:13 -1000
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-08 20:34 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 12:04 -0700
[OT] Haskell code Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 00:42 +0200
Re: [OT] Haskell code Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:14 -0700
Re: [OT] Haskell code Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:15 -0700
Re: [OT] Haskell code Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 03:10 +0200
Re: [OT] Haskell code Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:35 -0700
Re: [OT] Haskell code Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 03:17 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-06 16:48 -0500
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 15:30 -0700
Re: Epic Fail Lars Brinkhoff <lars.spam@nocrew.org> - 2014-04-07 11:26 +0200
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 05:21 -0500
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-07 17:54 +0100
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-07 12:14 -0500
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-07 16:49 +0000
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-07 09:37 +0000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-06 08:43 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-07 12:53 +0000
Re: Epic Fail mhx@iae.nl - 2014-04-06 00:09 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-06 13:12 +0000
Re: Epic Fail mhx@iae.nl - 2014-04-06 07:55 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-07 10:18 +0000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 08:21 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-06 08:30 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-06 22:12 +0200
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-06 12:08 -1000
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-06 16:44 -0700
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-06 22:03 -0700
Re: Epic Fail Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-04-07 01:29 -0700
locals in nested definitions (was: Epic Fail) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-07 16:57 +0000
Re: Epic Fail mhx@iae.nl - 2014-04-07 11:48 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 22:54 +0200
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-08 00:04 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 14:12 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-07 21:23 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-07 19:33 -1000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-07 23:52 -0700
Re: Epic Fail Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-04-08 09:07 +0100
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-08 12:35 +0100
Re: Epic Fail anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-08 16:21 +0000
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-08 16:33 -0400
Re: Epic Fail "Alex McDonald" <blog@rivadpm.com> - 2014-04-08 23:41 +0100
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-08 22:47 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-08 10:43 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 07:22 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-08 10:12 -0500
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 08:58 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-08 08:02 -1000
Re: Epic Fail hughaguilar96@yahoo.com - 2014-04-08 23:07 -0700
Re: Epic Fail albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-08 10:21 +0000
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-08 15:32 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-08 17:46 -0400
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 01:06 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:06 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 02:56 +0200
Re: Epic Fail Paul Rubin <no.email@nospam.invalid> - 2014-04-08 18:17 -0700
Re: Epic Fail Melzzzzz <mel@zzzzz.com> - 2014-04-09 03:24 +0200
Re: Epic Fail "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-09 02:22 -0400
Re: Epic Fail Ron Aaron <rambamist@gmail.com> - 2014-04-09 17:07 +0300
Re: Epic Fail the_gavino_himself <visphatesjava@gmail.com> - 2014-04-09 03:48 -0700
Re: Epic Fail Ron Aaron <rambamist@gmail.com> - 2014-04-07 07:17 +0300
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-07 22:52 +0200
Re: Epic Fail Mark Wills <markwills1970@gmail.com> - 2014-04-07 03:53 -0700
Re: Epic Fail the_gavino_himself <visphatesjava@gmail.com> - 2014-04-08 16:24 -0700
Re: Epic Fail the_gavino_himself <visphatesjava@gmail.com> - 2014-04-08 16:45 -0700
Re: Epic Fail kerdezixe@gmail.com - 2014-04-29 11:15 -0700
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-29 11:21 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-29 20:46 +0200
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-29 12:27 -0700
Re: Epic Fail Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-29 23:13 +0200
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-30 00:04 -0700
Re: Epic Fail Mark Wills <markwills1970@gmail.com> - 2014-04-30 00:54 -0700
Re: Epic Fail Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-30 03:08 -0500
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-30 02:30 -0700
Re: Epic Fail AKK <akk@nospam.org> - 2014-04-29 20:48 +0200
Re: Epic Fail stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-29 19:09 +0000
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-29 09:23 -1000
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-29 12:43 -0700
Re: Epic Fail "Elizabeth D. Rather" <erather@forth.com> - 2014-04-29 11:23 -1000
Re: Epic Fail Laurent Laborde <kerdezixe@gmail.com> - 2014-04-29 22:52 -0700
Page 15 of 19 — ← Prev page 1 … 13 14 [15] 16 17 … 19 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-07 08:43 -0500 |
| Message-ID | <DqidnTAe0dYZNt_OnZ2dnUVZ8sGdnZ2d@supernews.com> |
| In reply to | #29374 |
Melzzzzz <mel@zzzzz.com> wrote: > On Mon, 07 Apr 2014 05:20:53 -0500 > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > >> Melzzzzz <mel@zzzzz.com> wrote: >> > On Mon, 07 Apr 2014 03:24:20 -0500 >> > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >> > >> >> Melzzzzz <mel@zzzzz.com> wrote: >> >> > On Sun, 06 Apr 2014 16:29:57 -0700 >> >> > Paul Rubin <no.email@nospam.invalid> wrote: >> >> > >> >> >> Melzzzzz <mel@zzzzz.com> writes: >> >> >> > I think you don't know how exactly GC works. Sweep faze can >> >> >> > be done in parallel with program, no question, but scanning >> >> >> > part cannot. Problem is not sweep but scan. >> >> >> >> >> >> Oh ok, by scanning you mean what is called the mark phase in >> >> >> mark-sweep style collectors. Yes, both parts can be done >> >> >> concurrently with the application, e.g. "treadmill" GC. >> >> > >> >> > treadmill is not about that as I read it. Still >> >> > >> >> >> >> some application threads keep running while others are being >> >> >> >> GC'd. >> >> >> > Impossible without knowing exactly what application does. >> >> >> >> >> >> All that's needed is for the objects to not interfere, which is >> >> >> doable if the language is set up for that. Erlang works that >> >> >> way (user threads are completely isolated from each other, so >> >> >> there can be a separate GC for each thread), for example. >> >> > >> >> > Problem is that user thread allocates all the time and accesses >> >> > it's memory. GC is just another thread it cannot access >> >> > application memory without locking or blocking. >> >> >> >> Whyever not? >> > >> > Because memory picture must not change during scanning. >> > When scanning for references to memory blocks, memory has to be >> > freezed, references to memory blocks and new memory blocks must not >> > be updated or created. Besides that every access to reference from >> > application has to be locked! >> >> As long as the application accesses memory correctly and follows the >> GC rules it will be fine. > > How this can be done? What you mean by this? I mean that the compiler has to be aware of the fact that the GC can move things and not hang on to interior pointers, for example. The compiler might have to add read barriers or write barriers. >> Any compiler generating code for a garbage-collected system has to >> know that things will be moved under its feet. > Only if application uses raw pointers. GC updates all references > after move operation normally. Especially in this case GC > has to stop application. No, it does not have to stop the application. Do I need to explain all this? You could just look it up: see researcher.ibm.com/files/us-groved/rc24504.pdf for just one example. Look at its list of references. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2014-04-07 20:27 +0200 |
| Message-ID | <lhuqls$h52$2@news.albasani.net> |
| In reply to | #29376 |
On Mon, 07 Apr 2014 08:43:32 -0500 Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Melzzzzz <mel@zzzzz.com> wrote: > > On Mon, 07 Apr 2014 05:20:53 -0500 > > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > > > >> Melzzzzz <mel@zzzzz.com> wrote: > >> > On Mon, 07 Apr 2014 03:24:20 -0500 > >> > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > >> > > >> >> Melzzzzz <mel@zzzzz.com> wrote: > >> >> > On Sun, 06 Apr 2014 16:29:57 -0700 > >> >> > Paul Rubin <no.email@nospam.invalid> wrote: > >> >> > > >> >> >> Melzzzzz <mel@zzzzz.com> writes: > >> >> >> > I think you don't know how exactly GC works. Sweep faze can > >> >> >> > be done in parallel with program, no question, but scanning > >> >> >> > part cannot. Problem is not sweep but scan. > >> >> >> > >> >> >> Oh ok, by scanning you mean what is called the mark phase in > >> >> >> mark-sweep style collectors. Yes, both parts can be done > >> >> >> concurrently with the application, e.g. "treadmill" GC. > >> >> > > >> >> > treadmill is not about that as I read it. Still > >> >> > > >> >> >> >> some application threads keep running while others are > >> >> >> >> being GC'd. > >> >> >> > Impossible without knowing exactly what application does. > >> >> >> > >> >> >> All that's needed is for the objects to not interfere, which > >> >> >> is doable if the language is set up for that. Erlang works > >> >> >> that way (user threads are completely isolated from each > >> >> >> other, so there can be a separate GC for each thread), for > >> >> >> example. > >> >> > > >> >> > Problem is that user thread allocates all the time and > >> >> > accesses it's memory. GC is just another thread it cannot > >> >> > access application memory without locking or blocking. > >> >> > >> >> Whyever not? > >> > > >> > Because memory picture must not change during scanning. > >> > When scanning for references to memory blocks, memory has to be > >> > freezed, references to memory blocks and new memory blocks must > >> > not be updated or created. Besides that every access to > >> > reference from application has to be locked! > >> > >> As long as the application accesses memory correctly and follows > >> the GC rules it will be fine. > > > > How this can be done? What you mean by this? > > I mean that the compiler has to be aware of the fact that the GC can > move things and not hang on to interior pointers, for example. The > compiler might have to add read barriers or write barriers. > > >> Any compiler generating code for a garbage-collected system has to > >> know that things will be moved under its feet. > > > Only if application uses raw pointers. GC updates all references > > after move operation normally. Especially in this case GC > > has to stop application. > > No, it does not have to stop the application. Do I need to explain > all this? You could just look it up: see > researcher.ibm.com/files/us-groved/rc24504.pdf for just one example. > Look at its list of references. Heh, I didn't believe someone would venture in actually implementing this ;) Cost of pointer/reference access is pretty high in this case I guess. Unfortunately I can't find experiences with this collector as it is only implementation I found that does this. -- Click OK to continue...
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-04-07 02:57 -0500 |
| Message-ID | <hYqdndu7jd4bx9_OnZ2dnUVZ7sadnZ2d@supernews.com> |
| In reply to | #29337 |
Paul Rubin <no.email@nospam.invalid> wrote: > Melzzzzz <mel@zzzzz.com> writes: >> One thing that is needed in functional world, that is GC (lot of >> closures and recursion), is not needed at all in OO world. > > Eh? Java, Python, Ruby, and even Forth aren't particularly > "functional", but benefit from GC. > >> Languages that don't force GC (or minimize it's use) will always >> perform better than languages that force usage of GC. > > GC done properly seems to cause a fairly minor speed hit, and a more > substantial memory footprint hit. That basically means you trade > software development expenses for hardware resource expenses (you need a > bigger computer to run the program). With today's hardware, the > tradeoff generally looks good for GC. In the 1970's it may have been > the other way around. I think that's right. If you can get away with statically- or stack-allocated memory allocation you'll get better performance than using GC, but if you're using dynamically-allocated memory GC may well be a good idea. In practice, the performance of a well-tuned collector competes well with ad hoc memory allocation schemes. In particular, a compacting collector has a super-fast allocation path: simply decrementing a pointer. As long as there's plenty of memory, collection can be done out of the critical path. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-04-07 10:00 +0000 |
| Message-ID | <53427755$0$24914$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #29359 |
In article <hYqdndu7jd4bx9_OnZ2dnUVZ7sadnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Paul Rubin <no.email@nospam.invalid> wrote: >> Melzzzzz <mel@zzzzz.com> writes: >>> One thing that is needed in functional world, that is GC (lot of >>> closures and recursion), is not needed at all in OO world. >> >> Eh? Java, Python, Ruby, and even Forth aren't particularly >> "functional", but benefit from GC. >> >>> Languages that don't force GC (or minimize it's use) will always >>> perform better than languages that force usage of GC. >> >> GC done properly seems to cause a fairly minor speed hit, and a more >> substantial memory footprint hit. That basically means you trade >> software development expenses for hardware resource expenses (you need a >> bigger computer to run the program). With today's hardware, the >> tradeoff generally looks good for GC. In the 1970's it may have been >> the other way around. > >I think that's right. If you can get away with statically- or >stack-allocated memory allocation you'll get better performance than >using GC, but if you're using dynamically-allocated memory GC may well >be a good idea. In practice, the performance of a well-tuned >collector competes well with ad hoc memory allocation schemes. In >particular, a compacting collector has a super-fast allocation path: >simply decrementing a pointer. As long as there's plenty of memory, >collection can be done out of the critical path. There is of course an other way we can use todays huge memories. Just never compact and never move, but unpage memory that is freed. If you ever wrap around the Zbyte memory space, repage as needed. I can imagine this works perfectly with a page size of 5K and a collection of images of about a Megabyte. "hardware assisted garbage collection". (Oops. I miss another patent opportunity.) > >Andrew. -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-07 16:10 +0200 |
| Message-ID | <lhubk8$g5c$1@online.de> |
| In reply to | #29359 |
Andrew Haley wrote: > I think that's right. If you can get away with statically- or > stack-allocated memory allocation you'll get better performance than > using GC, but if you're using dynamically-allocated memory GC may well > be a good idea. In practice, the performance of a well-tuned > collector competes well with ad hoc memory allocation schemes. In > particular, a compacting collector has a super-fast allocation path: > simply decrementing a pointer. As long as there's plenty of memory, > collection can be done out of the critical path. Actually, you can use that sort of super-fast allocater even when you don't use a GC to free things, but use explicit freeing/compacting. E.g. take region-based allocation: You allocate a region at the start of a process/function that is going to use some unknown amount of memory, and when you are done, you copy the result (explicitely) into a more presistent region, and free the temporary region. Super-fast (just increment the pointer), zero memory overhead allocation (no need to remember how big the memory space was), low-overhead freeing of regions you no longer need. And as each process has its own region, there are no conflicts in multithreading environments. Anton proposed this region based allocation some time ago; I think we should add that stuff into Gforth. It's really a more Forth-like way to do these things than GC. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | m.a.m.hendrix@tue.nl |
|---|---|
| Date | 2014-04-07 07:54 -0700 |
| Message-ID | <713f2e66-c299-462c-85a3-0097a59a1ff3@googlegroups.com> |
| In reply to | #29377 |
On Monday, April 7, 2014 4:10:16 PM UTC+2, Bernd Paysan wrote: > Andrew Haley wrote: [..] > Actually, you can use that sort of super-fast allocater even when you don't > use a GC to free things, but use explicit freeing/compacting. E.g. take > region-based allocation: You allocate a region at the start of a > process/function that is going to use some unknown amount of memory, and > when you are done, you copy the result (explicitely) into a more presistent > region, and free the temporary region. Super-fast (just increment the > pointer), zero memory overhead allocation (no need to remember how big the > memory space was), low-overhead freeing of regions you no longer need. And > as each process has its own region, there are no conflicts in multithreading > environments. You mean, like ALLOT works for tasks (or the terminal) :-) -marcel
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-07 22:59 +0200 |
| Message-ID | <lhv3kg$b0f$3@online.de> |
| In reply to | #29378 |
m.a.m.hendrix@tue.nl wrote: > On Monday, April 7, 2014 4:10:16 PM UTC+2, Bernd Paysan wrote: >> Andrew Haley wrote: > [..] >> Actually, you can use that sort of super-fast allocater even when you >> don't >> use a GC to free things, but use explicit freeing/compacting. E.g. take >> region-based allocation: You allocate a region at the start of a >> process/function that is going to use some unknown amount of memory, and >> when you are done, you copy the result (explicitely) into a more >> presistent >> region, and free the temporary region. Super-fast (just increment the >> pointer), zero memory overhead allocation (no need to remember how big >> the >> memory space was), low-overhead freeing of regions you no longer need. >> And as each process has its own region, there are no conflicts in >> multithreading environments. > > You mean, like ALLOT works for tasks (or the terminal) :-) Yes. With the difference that you can throw away a bunch of ALLOTed things in one go. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-07 15:07 -0700 |
| Message-ID | <7xzjjwoktf.fsf@ruckus.brouhaha.com> |
| In reply to | #29377 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > You allocate a region at the start of a process/function that is going > to use some unknown amount of memory, and when you are done, you copy > the result (explicitely) into a more presistent region You mean the application has to do this copying and adjust any pointers into the old region that exist anywhere in the system? Does the application also have to remember where the live objects are, in order to know what to copy? I'm not sure how this is different from traditional manual allocate/free.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-07 15:13 -0700 |
| Message-ID | <7xvbukokix.fsf@ruckus.brouhaha.com> |
| In reply to | #29409 |
Paul Rubin <no.email@nospam.invalid> writes: >> you copy the result (explicitely) into a more persistent region > You mean the application has to do this copying and adjust any pointers Well, ok, maybe I expected a little too much. As long as the result is a single object that doesn't contain any pointers that you're not willing to manually patch up, and the objects aren't shared/copied to too many places, and you rigorously follow the strategy through the whole program, then I guess it is workable.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-04-08 00:40 +0200 |
| Message-ID | <lhv9hc$pkj$1@online.de> |
| In reply to | #29410 |
Paul Rubin wrote: > Paul Rubin <no.email@nospam.invalid> writes: >>> you copy the result (explicitely) into a more persistent region >> You mean the application has to do this copying and adjust any pointers > > Well, ok, maybe I expected a little too much. As long as the result is > a single object that doesn't contain any pointers that you're not > willing to manually patch up, and the objects aren't shared/copied to > too many places, and you rigorously follow the strategy through the > whole program, then I guess it is workable. The general idea of these region is life-range splits. You free a region when you are done with something (calling a complex function, or a process). The process or the function may have results, and those results need to be copied before you can free the region. The idea is that the result is far smaller than the intermediate data you need to manipulate in order to calculate it. If you have objects which are shared, I suggest you should be allowed to construct new objects that contain pointers to existing objects, but not allowed to replace those pointers (i.e. follow the cons function in Lisp). Then, when you do the copy (and I expect that your object system will provide you with a generic copy word, so the app doesn't have to deal with all the pointers), this generic word will copy all objects of the to-be- freed region, and stop when it reaches objects which are in different regions. Just like a copying GC works. However, here we have this clean-up at well-defined places (the "return result" place), where we hopefully have minimized the amount of copies we need to make. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> |
|---|---|
| Date | 2014-04-07 01:02 +0100 |
| Message-ID | <0qp3k9ldq69fh0asm3k0686hapnt1l9vn0@4ax.com> |
| In reply to | #29334 |
On Sun, 06 Apr 2014 23:25:23 +0200, Bernd Paysan <bernd.paysan@gmx.de> wrote: > > If you think of teaching as long-term investment, teach them concepts, and a number >of very different languages so that they know that they don't know it all. > >What quite a lot of professors dodge in the 101 course is the "understanding >the machine" part. The following three articles are submitted as they may be of interest 1 -- the Perils of Java, 2 -- the secret weapon approach in choosing a language for a startup, 3 -- the difference between vocational training & education. [Article 1] The Perils of Java Schools - by Joel Spolsky http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html This was quite controversial when it came out, and Joel got flamed quite a bit for taking this position. It's interesting because Forth in many senses fits the bill for a language that stretches the mind as well as educates on the machine, data structures, layers of programming, and abstractions. A quote: "Pointers and recursion require a certain ability to reason, to think in abstractions, and, **most importantly, to view a problem at several levels of abstraction simultaneously.** And thus, the ability to understand pointers and recursion is directly correlated with the ability to be a great programmer." (emphasis mine) [Article 2] Beating the Averages - by Paul Graham http://www.paulgraham.com/avg.html Paul makes the argument why a startup can (and often should) depart from the technological norm in choosing their approach. He illustrates this example by choosing Lisp for his own startup --- and the competitive advantage that that brought him. Interestingly, one could make the same argument for Forth. And I wonder how many companies today have divisions that are doing exactly that? (I seem to recall reading that a division in BMW is using Forth? -- can't remember where I saw this) A quote: "...using Lisp was an experiment. Our hypothesis was that if we wrote our software in Lisp, we'd be able to get features done faster than our competitors, and also to do things in our software that they couldn't do. And because Lisp was so high-level, we wouldn't need a big development team, so our costs would be lower. If this were so, we could offer a better product for less money, and still make a profit. We would end up getting all the users, and our competitors would get none, and eventually go out of business. "What were the results of this experiment? Somewhat surprisingly, it worked [...] "Our secret weapon was [Lisp]. We wrote our software in a weird AI language, with a bizarre syntax full of parentheses. For years it had annoyed me to hear Lisp described that way. But now it worked to our advantage. In business, there is nothing more valuable than a technical advantage your competitors don't understand. In business, as in war, surprise is worth as much as force. "And so, I'm a little embarrassed to say, I never said anything publicly about Lisp while we were working on Viaweb. We never mentioned it to the press, and if you searched for Lisp on our Web site, all you'd find were the titles of two books in my bio. This was no accident. A startup should give its competitors as little information as possible. If they didn't know what language our software was written in, or didn't care, I wanted to keep it that way." [Article 3] The Perils of Joel Spolsky http://blog.markturansky.com/archives/38 One of a number of critical responses to Joel's claim. The issue boils down to whether education should be vocational training, in which case selecting vogue languages like Java or .Net is fine, versus academic training, in which case it is the concepts and not the language that is important --- the language just has to allow study of the concepts. It used to be believed that the role of universities is to educate for the long-term and not to worry about teaching vocational skills. Dijkstra for example was a very vocal opponent of the dilution of university education by industry wanting more vocational training and university administrators wanting the increased revenue that more students and more corporate grants would bring. In my view universities that teach computer science courses in Java or .Net are favouring vocational preparation over the more difficult business of teaching core concepts. This might produce more graduates -- these languages certainly help get the job done. As I see it C, Lisp, Forth are examples of languages whose learning furthers your education. They change the way you think about algorithms, about programming, and about the machine underneath it.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-08 10:49 -0700 |
| Message-ID | <7xsipnogni.fsf@ruckus.brouhaha.com> |
| In reply to | #29350 |
Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> writes: > http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html I thought this a pretty lame article. The points about Java are valid, but he's a little too obsessed with pointers and recursion, and anyway the SICP course that he likes (and that I like) doesn't use pointers except maybe toward the end where it discusses how to write a compiler. > It's interesting because Forth in many senses fits the bill for a > language that stretches the mind as well as educates on the machine, > data structures, layers of programming, and abstractions. It's seemed to me the opposite (at least from Chuck and Jeff's writings): part of Forth philosophy is to get rid of abstraction and search for the implementation that solves the problem directly instead of through multiple layers. This is IMHO one of the ideas that make Forth interesting, though trying to apply it to every area of programming isn't a great idea. > "Pointers and recursion require a certain ability to reason, to think > in abstractions, and, **most importantly, to view a problem at several > levels of abstraction simultaneously.** Sure, but each of those layers is using a chunk of your brainpower, so if you're using any of them on layers like low level i/o, memory management, etc., it's displacing capability that you could be using on the actual problem at hand. Java of course replaces layers of abstraction with layers of bureaucracy ;-). > [Article 2] Beating the Averages - by Paul Graham > http://www.paulgraham.com/avg.html This was a more interesting essay though Graham missed that Lisp is yet another Blub. He saw it at the top of the heap because when he looked upward all he saw was weird features, just like the Blub programmer he described. > Interestingly, one could make the same argument for Forth. No really, please don't say things like that without more HLL experience. Forth is great as a mental discipline and in certain application niches involving low-resource processors, real-time control, etc. However, it is (on purpose) mostly near the bottom of the abstraction tower. If you want to see something further up, try: http://learnyouahaskell.com . > "Our secret weapon was [Lisp]. We wrote our software in a weird AI > language, with a bizarre syntax full of parentheses. Lisp really was a secret weapon in the 1980's, but its good points have been taken up by other languages by now. > [Article 3] The Perils of Joel Spolsky > http://blog.markturansky.com/archives/38 This basically says you don't need much CS knowledge to write CRUD apps. True, and not surprising. So? > As I see it C, Lisp, Forth are examples of languages whose learning > furthers your education. They change the way you think about > algorithms, about programming, and about the machine underneath it. Fair enough. I'd add Erlang, Haskell, assembler, and (on my list, at opposite ends of the abstraction scale) Coq and Verilog.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-04-08 19:01 +0100 |
| Message-ID | <li1dhm$af2$1@dont-email.me> |
| In reply to | #29453 |
on 08/04/2014 18:49:40, Paul Rubin wrote: > Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> writes: > >> As I see it C, Lisp, Forth are examples of languages whose learning >> furthers your education. They change the way you think about >> algorithms, about programming, and about the machine underneath it. > > Fair enough. I'd add Erlang, Haskell, assembler, and (on my list, at > opposite ends of the abstraction scale) Coq and Verilog. > And COBOL. Before you all fall around laughing, I'm talking about the classic 1950s/60s version of COBOL. Knowing it (and I don't just mean knowing the history, but the language) will help you understand why it was (a) necessary (b) successful and (c) became, along with its practitioners, so widely despised. (a) will give you insight as to why there are so many languages and what issues they try to solve; COBOL fixed one well and failed almost everywhere else (b) will show you that oftentimes, anything is better than assembler; COBOL was easier to specify, write and maintain. (c) will give you the foresight to consider the probable fate for your "langue du jour". Like COBOL, it's going to suck fairly soon.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-04-08 08:13 -1000 |
| Message-ID | <apOdnfRnW5XTodnOnZ2dnUVZ_jydnZ2d@supernews.com> |
| In reply to | #29455 |
On 4/8/14 8:01 AM, Alex McDonald wrote: > on 08/04/2014 18:49:40, Paul Rubin wrote: >> Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> writes: > >> >>> As I see it C, Lisp, Forth are examples of languages whose learning >>> furthers your education. They change the way you think about >>> algorithms, about programming, and about the machine underneath it. >> >> Fair enough. I'd add Erlang, Haskell, assembler, and (on my list, at >> opposite ends of the abstraction scale) Coq and Verilog. >> > > And COBOL. Before you all fall around laughing, I'm talking about the > classic 1950s/60s version of COBOL. Knowing it (and I don't just mean > knowing the history, but the language) will help you understand why it > was (a) necessary (b) successful and (c) became, along with its > practitioners, so widely despised. > > (a) will give you insight as to why there are so many languages and what > issues they try to solve; COBOL fixed one well and failed almost > everywhere else (b) will show you that oftentimes, anything is better > than assembler; COBOL was easier to specify, write and maintain. > (c) will give you the foresight to consider the probable fate for your > "langue du jour". Like COBOL, it's going to suck fairly soon. In 1971-2 I managed a group of COBOL programmers and wrote a fair amt of COBOL myself. Yes, it was an interesting learning experience, and I agree with all those observations! Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2014-04-08 20:34 +0200 |
| Message-ID | <li1ffg$j4h$1@news.albasani.net> |
| In reply to | #29453 |
On Tue, 08 Apr 2014 10:49:37 -0700 Paul Rubin <no.email@nospam.invalid> wrote: > Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> writes: > > > [Article 2] Beating the Averages - by Paul Graham > > http://www.paulgraham.com/avg.html > > This was a more interesting essay though Graham missed that Lisp is > yet another Blub. He saw it at the top of the heap because when he > looked upward all he saw was weird features, just like the Blub > programmer he described. > > > Interestingly, one could make the same argument for Forth. > > No really, please don't say things like that without more HLL > experience. Forth is great as a mental discipline and in certain > application niches involving low-resource processors, real-time > control, etc. However, it is (on purpose) mostly near the bottom of > the abstraction tower. If you want to see something further up, try: > http://learnyouahaskell.com . > Heh, when I first saw Haskell it was love on first site. But Haskell is extremely difficult language to master. Much more difficult than C++, IMO. Problem is that I can't understand it properly even now after ~5 years. -- Click OK to continue...
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-08 12:04 -0700 |
| Message-ID | <7xy4zf63sb.fsf@ruckus.brouhaha.com> |
| In reply to | #29458 |
Melzzzzz <mel@zzzzz.com> writes: > But Haskell is extremely difficult language to master. Yes, that's sort of the point, it requires building up levels of understanding that aren't required in other languages, but are useful once you have them. > Problem is that I can't understand it properly even now after ~5 years. I'm not that good at it either.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2014-04-09 00:42 +0200 |
| Subject | [OT] Haskell code Re: Epic Fail |
| Message-ID | <li1u11$kjq$1@news.albasani.net> |
| In reply to | #29459 |
On Tue, 08 Apr 2014 12:04:52 -0700
Paul Rubin <no.email@nospam.invalid> wrote:
> Melzzzzz <mel@zzzzz.com> writes:
> > But Haskell is extremely difficult language to master.
>
> Yes, that's sort of the point, it requires building up levels of
> understanding that aren't required in other languages, but are useful
> once you have them.
>
> > Problem is that I can't understand it properly even now after ~5
> > years.
>
> I'm not that good at it either.
Just look at this short and elegant program:
http://rosettacode.org/wiki/9_billion_names_of_God_the_integer#Haskell
Problem is that it needs more than 10 gigabytes and lot of time to
calculate sum of all combinations that produce particular sums.
So I have looked into C solution and wrote this:
{-# Language BangPatterns #-}
import System.IO.Unsafe
import Data.Bits ((.&.))
import Data.List (mapAccumL)
import qualified Data.Vector.Mutable as VM
import qualified Data.Vector.Generic.Mutable as VG
n :: Int
n = 100000
p :: VM.IOVector Integer
p = unsafePerformIO $ VG.new (n+1)
toBool i = if i == 0 then False else True
calc :: Int -> IO()
calc n = do
VM.write p n 0
let loop :: Int -> IO()
loop k = do
let !d = n - k * (3 * k - 1) `quot` 2
let f d = if d >= 0
then do
if toBool $ k .&. 1
then do
!pn <- VM.unsafeRead p n
!pd <- VM.unsafeRead p d
VM.unsafeWrite p n (pn+pd)
else do
!pn <- VM.unsafeRead p n
!pd <- VM.unsafeRead p d
VM.unsafeWrite p n (pn-pd)
return True
else return False
fd <- f d
if fd
then do
fdk <- f (d-k)
if fdk
then if k <= n
then loop (k+1)
else return ()
else return ()
else return ()
loop 1
cumu :: [[Integer]]
cumu = [1] : map (scanl (+) 0) rows
rows :: [[Integer]]
rows = snd $ mapAccumL f [] cumu where
f r row = (rr, new_row) where
new_row = map head rr
rr = map tailKeepOne (row:r)
tailKeepOne [x] = [x]
tailKeepOne (_:xs) = xs
sums n = cumu !! n !! n
--curiously, the following seems to be faster
--sums = sum . (rows!!)
main :: IO ()
main = do
mapM_ (\x -> putStrLn $ replicate (25 - length x) ' ' ++ show x) $ take 25 rows
-- mapM_ (print.sums) [23, 123, 1234, 12345]
let idx = [23, 123, 1234, 12345, 20000, 30000, 40000, 50000, n]
VM.write p 0 1
let loop i idx = do
calc i
if i == idx
then do
vidx <- VM.read p idx
putStrLn $ show i ++ " " ++ show vidx
return (i+1)
else do
loop (i+1) idx
printSums i (x:idx) = do
i <- loop i x
printSums i idx
printSums _ [] = return ()
printSums 1 idx
Now it needs less than 20mb and about 3.5secs to display
all of these sums.
Take away exclamation marks (strictness annotation)
and it will need 800mb of stack size and 18secs ;)
--
Click OK to continue...
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-08 18:14 -0700 |
| Subject | Re: [OT] Haskell code Re: Epic Fail |
| Message-ID | <7xha63gv8d.fsf@ruckus.brouhaha.com> |
| In reply to | #29464 |
Melzzzzz <mel@zzzzz.com> writes: > http://rosettacode.org/wiki/9_billion_names_of_God_the_integer#Haskell > Problem is that it needs more than 10 gigabytes and lot of time to > calculate sum of all combinations that produce particular sums. Sounds like it just didn't use the right algorithm. I don't think you had to write that C-like code. > p = unsafePerformIO $ VG.new (n+1) Nooooo.... and if you MUST do that, you have to use pragma noinline. > toBool i = if i == 0 then False else True toBool = (== 0) -- but why do you want that > Take away exclamation marks (strictness annotation) > and it will need 800mb of stack size and 18secs ;) Maybe you could get even more speedup with unboxed ints.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-04-08 18:15 -0700 |
| Subject | Re: [OT] Haskell code Re: Epic Fail |
| Message-ID | <7xd2grgv6y.fsf@ruckus.brouhaha.com> |
| In reply to | #29470 |
Paul Rubin <no.email@nospam.invalid> writes: > toBool = (== 0) -- but why do you want that That's (/= 0)
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2014-04-09 03:10 +0200 |
| Subject | Re: [OT] Haskell code Re: Epic Fail |
| Message-ID | <li26mr$2tq$2@news.albasani.net> |
| In reply to | #29470 |
On Tue, 08 Apr 2014 18:14:10 -0700 Paul Rubin <no.email@nospam.invalid> wrote: > Melzzzzz <mel@zzzzz.com> writes: > > http://rosettacode.org/wiki/9_billion_names_of_God_the_integer#Haskell > > Problem is that it needs more than 10 gigabytes and lot of time to > > calculate sum of all combinations that produce particular sums. > > Sounds like it just didn't use the right algorithm. I don't think > you had to write that C-like code. > It is mutable array friendly algorithm. Can't use linked lists efficiently. Code could probably be prettier but essentially same. > > p = unsafePerformIO $ VG.new (n+1) > > Nooooo.... and if you MUST do that, you have to use pragma noinline. Oh, I never thought about inlining ... Just inlined it and of course it fails ;( > > > toBool i = if i == 0 then False else True > > toBool = (== 0) -- but why do you want that because .&. returns Int and I have to convert it to Bool. > > > Take away exclamation marks (strictness annotation) > > and it will need 800mb of stack size and 18secs ;) > > Maybe you could get even more speedup with unboxed ints. Cannot do that. I have to use Integer as it is big int arithmetic. -- Click OK to continue...
[toc] | [prev] | [next] | [standalone]
Page 15 of 19 — ← Prev page 1 … 13 14 [15] 16 17 … 19 Next page →
Back to top | Article view | comp.lang.forth
csiph-web