{"action":"created","issue":{"url":"https://api.github.com/repos/donaldsonjw/bigloo/issues/1","labels_url":"https://api.github.com/repos/donaldsonjw/bigloo/issues/1/labels{/name}","comments_url":"https://api.github.com/repos/donaldsonjw/bigloo/issues/1/comments","events_url":"https://api.github.com/repos/donaldsonjw/bigloo/issues/1/events","html_url":"https://github.com/donaldsonjw/bigloo/issues/1","id":58888766,"number":1,"title":"Wasn't this supposed to be a version that could be compiled with Msys2 Mingw-W64?","user":{"login":"GordonBGood","id":10696269,"avatar_url":"https://avatars.githubusercontent.com/u/10696269?v=3","gravatar_id":"","url":"https://api.github.com/users/GordonBGood","html_url":"https://github.com/GordonBGood","followers_url":"https://api.github.com/users/GordonBGood/followers","following_url":"https://api.github.com/users/GordonBGood/following{/other_user}","gists_url":"https://api.github.com/users/GordonBGood/gists{/gist_id}","starred_url":"https://api.github.com/users/GordonBGood/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/GordonBGood/subscriptions","organizations_url":"https://api.github.com/users/GordonBGood/orgs","repos_url":"https://api.github.com/users/GordonBGood/repos","events_url":"https://api.github.com/users/GordonBGood/events{/privacy}","received_events_url":"https://api.github.com/users/GordonBGood/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":{"login":"donaldsonjw","id":500866,"avatar_url":"https://avatars.githubusercontent.com/u/500866?v=3","gravatar_id":"","url":"https://api.github.com/users/donaldsonjw","html_url":"https://github.com/donaldsonjw","followers_url":"https://api.github.com/users/donaldsonjw/followers","following_url":"https://api.github.com/users/donaldsonjw/following{/other_user}","gists_url":"https://api.github.com/users/donaldsonjw/gists{/gist_id}","starred_url":"https://api.github.com/users/donaldsonjw/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/donaldsonjw/subscriptions","organizations_url":"https://api.github.com/users/donaldsonjw/orgs","repos_url":"https://api.github.com/users/donaldsonjw/repos","events_url":"https://api.github.com/users/donaldsonjw/events{/privacy}","received_events_url":"https://api.github.com/users/donaldsonjw/received_events","type":"User","site_admin":false},"milestone":null,"comments":32,"created_at":"2015-02-25T11:40:01Z","updated_at":"2015-03-22T02:08:27Z","closed_at":null,"body":"Since the master branch is supposed to be a merged trunk of the LLP64 and Win64 branches, one might assume that this version would be able to be compiled by Msys2 with Mingw-W64-x86_64 but that is not the case:\r\n\r\nAlthough there has obviously been some work done to adapt Bigloo to Windows such as the _BGL_WIN32_VER define used to discriminate between Posix socket.h and Windows Winsock.h usage, even that isn't working with Mingw as the bigloo.h file has an reference to socket.h (and others) guarded by the above define that isn't defined by all files that might include bigloo.h.\r\n\r\nIn addition, new bugs have been introduced such as the \"sa_family_t\" type used in bigloo.h and not defined anywhere - it is almost as if this version of bitloo.h wasn't the intended version for this package.\r\n\r\nFurther, none of the LLP64 adaptations mentioned in your post as of:  http://comments.gmane.org/gmane.lisp.scheme.bigloo/6214 made it into this version, including the BGL_LONG_T and BGL_LONG_T types and the other macro and program fixes mentioned there, nor are there patch files provided as for the version mentioned there (although the files downloaded from the follow-on post's links are corrupted).\r\n\r\nIt seems that this git is nothing but the same version as provided on the Bigloo website as of 6 January 2015, with no changes made to it whatsoever; perhaps you should modify the README file to reflect exactly that, and perhaps post to the ChangeLog that these git's have only been copied over with no changes yet made so those that find this git don't waste time trying to compile it with MSys2?"},"comment":{"url":"https://api.github.com/repos/donaldsonjw/bigloo/issues/comments/84494112","html_url":"https://github.com/donaldsonjw/bigloo/issues/1#issuecomment-84494112","issue_url":"https://api.github.com/repos/donaldsonjw/bigloo/issues/1","id":84494112,"user":{"login":"GordonBGood","id":10696269,"avatar_url":"https://avatars.githubusercontent.com/u/10696269?v=3","gravatar_id":"","url":"https://api.github.com/users/GordonBGood","html_url":"https://github.com/GordonBGood","followers_url":"https://api.github.com/users/GordonBGood/followers","following_url":"https://api.github.com/users/GordonBGood/following{/other_user}","gists_url":"https://api.github.com/users/GordonBGood/gists{/gist_id}","starred_url":"https://api.github.com/users/GordonBGood/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/GordonBGood/subscriptions","organizations_url":"https://api.github.com/users/GordonBGood/orgs","repos_url":"https://api.github.com/users/GordonBGood/repos","events_url":"https://api.github.com/users/GordonBGood/events{/privacy}","received_events_url":"https://api.github.com/users/GordonBGood/received_events","type":"User","site_admin":false},"created_at":"2015-03-22T02:08:27Z","updated_at":"2015-03-22T02:08:27Z","body":"Hello Joe,\n\nThanks for the update on the new version of Larceny; I was wrong that\ndevelopment has stopped.  I have downloaded the (32-bit) Windows version\nand will run some benchmarks.\n\nI'm afraid I must admit that I have not done much on Scheme this past week\nas there is a new version of Haskell in Release Candidate 3 that I wanted\nto test.  I think that perhaps Haskell would be my preferred functional\nlanguage as to performance and concise source code but lacks a good IDE\n(although the Haskell Platform is very usable for debugging and there is\nLeksah - EclipseFP isn't current to latest versions) and the LLVM backend\nstill doesn't work under Windows 64 (not Haskell's problem but a bug in\nbinutils under Windows, which it uses); now that the problem is known, it\nwill probably get fixed by the next release in about a year.  A lot of\n(Microsoft Research funded) research has been done on the Haskell custom\ngarbage collector and compiler and it generates the fastest code for the\nleast source code I have ever seen (although the current native code\ngenerator stinks and one must use the LLVM back end for the fastest code).\nIt usually runs faster than Cee as long as one pays attention to strictness\n(Haskell is lazy by default).  It has very stable native thread support\nalthough implemented as light threads with native threading scheduling.\n\nI got thinking this week that perhaps srfi18 doesn't run under my system\ndue to something about the build process I used, and should really rebuilt\nmy release.  I'll build your latest archive and if there are further\nproblems I report them to you.  Last time I did a standard build just as I\nhad done before, but did run \"make test\" before running \"make install\"\n(having already set --prefix= to my install directory in ./configure); I'm\nwondering if \"make test\" somehow corrupted or changed some files before the\ninstalll.  As you have already run \"make test\", this time I will go\ndirectly to \"make install\" after a successful \"make\" and then perhaps run\n\"make test\" after the files are already safely installed.\n\nThanks for the work on a SRFI-18 compliant \"mutex-unlock!\" and the number\nof processors.  Not being able to test currently, IIRC the \"mutex-lock!\" is\nalso not quite SRFI compliant in that it doesn't accept the third \"thread\"\nargument to assign a specific thread as owner, not that most programs would\nuse that and would accept the default of assigning \"current-thread\" as\nowner when given this form.  I'll check this again once srfi18 works again.\n\nFor an example of what Haskell can do that seemingly no other programming\nlanguage can is the Hamming problem, as I encountered on ProgrammingPraxis\nat http://programmingpraxis.com/2015/03/06/357-numbers/.\n\nMy best Scheme implementation for Bigloo is as follows (using Co Inductive\nStreams as Scheme has no lazy list):\n\n```scheme\n(module test (main start))\n\n(define (gettime thnk)\n  (let ((strt (current-microseconds))\n        (rslt (thnk))\n        (stop (current-microseconds)))\n    (begin (print \"Elapsed time:  \" (quotientllong (-llong stop strt)\n#l1000) \" milliseconds.\") rslt)))\n\n(define (s357)\n  (define (merge x y)\n    (let ((xv (car x)) (yv (car y)))\n      (cond ((< xv yv) (cons xv (lambda () (merge ((cdr x)) y))))\n                ((> xv yv) (cons yv (lambda () (merge x ((cdr y))))))\n                (else (cons xv (lambda () (merge ((cdr x)) y)))))))\n  (define (smult s m) (cons (* (car s) m) (lambda () (smult ((cdr s))\nm)))) ;; equiv to map (* m)\n  (define (s3 n) (cons n (lambda () (s3 (* n 3)))))\n  (define (s35) (cons 1 (lambda () (merge (s3 3) (smult (s35) 5)))))\n  (cons 1 (lambda () (merge ((cdr s35r)) (smult (s357) 7)))))\n\n;;; test...\n(define limit 100000)\n(define (countemto lmt)(do ((nxt (s357) ((cdr nxt))) (cnt 0 (+ cnt 1)))\n((>= cnt lmt) (car nxt))))\n(define (start argvs) (display (gettime (lambda () (countemto limit)))\n(newline)))\n```\n\nWhere Haskell can be written as (this order produces slightly faster code\non my machine):\n\n```haskell\n{-# OPTIONS -O2 -optc-O3 -rtsopts -fllvm #-}\n\nimport Data.Function (fix)\n\nhamm :: () -> [Integer]\nhamm() = 1 : foldl (\\s n -> fix (merge s . (n:) . map (n*))) [] [7,5,3]\n  where merge [] b = b\n        merge a [] = a\n        merge a@(x:xs) b@(y:ys) = if x < y then x : merge xs b\n                                  else y : merge a ys\n\nmain = do\n  print $ (hamm()) !! (10000000 - 1)\n```\nWhen run as \"seq357 +RTS -s\" the Haskell code runs at about 3.4 seconds\ntotal time on my machine with a little over half spent in garbage\ncollection whereas compiled Bigloo (-Obench -copts \"-O3\") runs the previous\ncode at about  4.4 seconds total time for about a hundredth of the work\n(the sequence is approximately linear computational complexity with number\nof elements in the sequence).  Gambit-C is a little faster at this as it\ndoesn't doe Cee function calls but rather sturctured goto's and thus avoids\nsome of the call overhead, but still is effectively making procedure calls,\njust slightly short circuited.\n\nI chalk Haskell's (32-bit compiler version 7.8.3 under latest Haskell\nPlatform on Windows)  performance up to optimizing away procedure calls and\nmore efficient garbage collection.  What do you think?\n\nI think that this is a good example of the application of pure functional\nprogramming principles actually being able to outperform more imperative\ncode due to the optimizations that can be made and shows even Schemes\nlimitations (due to its age and not really being completely \"pure\", with\n\"set!\" procedures part of the language).\n\nBest regards, Gordon\n\nOn Sun, Mar 22, 2015 at 3:05 AM, Joseph Donaldson <notifications@github.com>\nwrote:\n\n> Hello, Gordon,\n>\n> I did not get to look at srfi18 last weekend but am doing so today, and I\n> am not seeing the linking problems you reported. The sample code you\n> provide compiled and ran with both the pthread and srfi18 libraries. Do you\n> recall what symbols were giving you problems? I took a jab at adding a\n> srfi18 compliant version of mutex-unlock!. I used the following code to\n> test:\n>\n> (module test (library srfi18) (main start))\n>\n> (define (test)\n>   (define loops 1000)\n>   (define m (make-mutex))\n>   (define cv (make-condition-variable))\n>   (define rdycv (make-condition-variable))\n>   (define t (make-thread (lambda ()\n>       (do () ((=fx 0 1)) (begin (mutex-lock! m)\n>                                 (thread-specific-set! t 42)\n>                                 (condition-variable-signal! rdycv)\n>                                 (mutex-unlock! m cv))))))\n>   (define (runthrd)\n>     (begin (mutex-lock! m)\n>            (let ((rslt (thread-specific t)))\n>              (begin (condition-variable-signal! cv) (mutex-unlock! m) rslt))))\n>   (begin (mutex-lock! m) (thread-start! t)  (mutex-unlock! m rdycv)\n>          (do ((i 0 (+fx i 1)) (cnt 0 (+fx cnt (runthrd)))) ((>=fx i loops) (begin (thread-terminate! t) cnt)))))\n>\n>\n> (define (gettime thnk)\n>   (let ((strt (current-microseconds))\n>         (rslt (thnk))\n>         (stop (current-microseconds)))\n>     (begin (print \"Elapsed time:  \" (quotientllong (-llong stop strt) #l1000) \" milliseconds.\") rslt)))\n>\n>\n> (define (start argv) (let ((count (gettime test))) (print \"Found \" count \" somethings.\")))\n>\n> I believe I captured the semantics correctly but could be mistaken. My\n> definition is\n>\n> (define (mutex-unlock! mutex #!optional condvar timeout)\n>   (when condvar\n>     (if timeout\n>         (condition-variable-wait! condvar mutex timeout)\n>         (condition-variable-wait! condvar mutex)))\n>   ((@ mutex-unlock!  __thread) mutex))\n>\n> A Bigloo archive containing the changes can be found at\n> https://sandjsite.net/jwd/files/bigloo4.2a_srfi18mod.tar.gz.\n>\n> Additionaly, I looked into obtaining the number of processors, and for\n> bigloo's native backend, the following code snippet should do so in a\n> portable fashion, since bigloo's native backend depends on pthreads for\n> threads on all supported platforms.\n>\n> (define (number-of-processors)\n>   (pragma::long \"pthread_num_processors_np();\"))\n>\n> We could do something very similar for the jvm backend by calling\n>\n> Runtime.getRuntime().availableProcessors()\n>\n> By the way, I noticed that a new version of Larceny was released; it may\n> be worth looking at.\n>\n> Best Regards,\n> Joe\n>\n> —\n> Reply to this email directly or view it on GitHub\n> <https://github.com/donaldsonjw/bigloo/issues/1#issuecomment-84447679>.\n>\n"}}