I just tried to upload a new Haskell package and ran into some difficulties.
If I just try to upload, it fails and says I need to contact somebody in the
trustees group to be added to the Uploaders group.
If I try to upload a package candidate instead, it says Forbidden,
No access for this resour
sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Mon, Mar 27, 2023 at 10:55 AM Phyx wrote:
> Thanks, that does indeed look dynamically linked.
>
> Could you also paste on the ticket the contents of hR.buildinfo?
>
> Cheers,
> Tamar
>
> Sent from
R_NilValue should never change during initialization so I'm
> more suspicious of how it's declared. Unless you're linking to a symbol in
> a shared library, in which case that could be possible due to ASLR.
>
> Kind regards,
> Tamar
>
> Sent from my Mobile
>
&g
Ben
>
> On March 25, 2023 6:49:09 PM EDT, Dominick Samperi
> wrote:
>>
>> Hello,
>> FFI code that used to work now fails under Windows (still seems to work
>> under Ubuntu), and I wonder if anybody has seen anything like this and
>> can provide some pointers..
Hello,
FFI code that used to work now fails under Windows (still seems to work
under Ubuntu), and I wonder if anybody has seen anything like this and
can provide some pointers...
The code uses FFI to fetch information from the R side like R_NilValue,
using something like this;
-- Fetch R's R_NilV
way things used to be when there was only
cygwin.
On Tue, Feb 21, 2023 at 7:55 PM Dominick Samperi
wrote:
> Thanks Recursion,
>
> I tried that, only installing GHCup and not MSYS and friends, then using
> Rtools
> version of MSYS, but this didn't work, perhaps because of a n
ing.
>
> Sent with Proton Mail <https://proton.me/> secure email.
>
> --- Original Message ---
> On Tuesday, February 21st, 2023 at 6:23 PM, Dominick Samperi <
> djsamp...@gmail.com> wrote:
>
> I watched an interesting YouTube video explaining how to install and
I watched an interesting YouTube video explaining how to install and use
the Haskell extension in VS code, but the information appears to be
obsolete, because there is no mention of ghcup, and ghcup is now
required, along with a new version of the Haskell extension (the old one
is labeled "legacy")
are you using?
>
> Is this on an arm flavor mac?
>
> On Thu, Jan 26, 2023 at 5:00 PM Ben Gamari wrote:
>
>> Dominick Samperi writes:
>>
>> > Hello,
>> >
>> > I have been working with a program that uses FFI to communicate with R
>> > for
Hello,
I have been working with a program that uses FFI to communicate with R for
several
years, but today there is a segmentation fault while importing functions or
data from R.
Before giving up on this project, I'm posting a few detail here, in case
anybody has
ideas...perhaps something changed
Hi,
Stack install does its thing in some hashed directory under .stack-work by
default,
but I want to write to /bin as part of the configure process.
I'm trying
to do this as follows:
-- configure file contains:
cd $(stack path --project-root)
echo "..." > .bin/foo.sh
cd -
> cd
> stack install
When I use v8.6.3 of GHC under Ubuntu to install the inline-r package
I get the error "Type family equation violates injectivity annotation," and
a type variable on the LHS cannot be inferred from the RHS, due to
the lack of injectivity (I suppose).
On the other hand, v8.0.2 of GHC (shipped with H
se then it might be impossible to link the temporary object files
> that it creates with the shared library.
>
> A workaround is to set "cc-options: -fPIC" in the .cabal file. But in my
> mind this is probably a Cabal bug.
>
> --
> Mathieu Boespflug
> Founder a
I should add that H builds and runs nicely under Windows and MacOS
(using ghc 8.0.1), so this is indeed a Fedora Linux issue.
On Sat, Aug 13, 2016 at 10:22 AM, Dominick Samperi wrote:
> Hello Mathieu,
>
> I'm using Fedora 23. The default Haskell Platform here provides ghc
> 7.8.
on? The -fPIC message from the linker
> may well be a red herring. AFAIR generating PIC is the default in GHC, at
> least for dynamic libraries.
>
> Best,
>
> --
> Mathieu Boespflug
> Founder at http://tweag.io.
>
> On 13 August 2016 at 05:55, Dominick Samperi wrote:
>&
Hello,
I am getting relocation errors when building an executable
(specifically, the "H"
executable -- part of haskellR) under Fedora Linux, and the message says to
"recompile with -fPIC".
The FAQ associated with H suggests that I switch to the gold linker
(ld.gold) due to bugs in the default lin
indicates that the package has been "certified" for
use with versions of base less than or equal to the upper limit.
On Mon, Jun 6, 2016 at 8:22 PM, Brandon Allbery wrote:
> On Mon, Jun 6, 2016 at 8:19 PM, Dominick Samperi
> wrote:
>>
>> The odd thing about this is t
are maintaining. Perhaps the answer to my original
question is that the maintainer of clash is also maintaining (part of)
base?
On Mon, Jun 6, 2016 at 5:13 PM, Brandon Allbery wrote:
> On Mon, Jun 6, 2016 at 5:02 PM, Dominick Samperi
> wrote:
>>
>> Consequently, it refuses t
Why would a package developer want to upper bound the version number
for packages like base? For example, the clash package requires
base >= 4.2 && base <= 4.3
Consequently, it refuses to install with the latest ghc provided with
the Haskell Platform (8.0.1).
Does this mean that assuming that fu
n Sat, Jun 27, 2015 at 2:53 PM, Dominick Samperi wrote:
> After much trial-and-error and web searching I found a work-around for
> ghci 7.10.1.
>
> It appears that BOTH extra-libraries and extra-lib-dirs must be
> specified in the cabal file. Previously the link parameters were
>
external linkage, and this is probably related to the problems
reported here.
On Sat, Jun 27, 2015 at 9:18 AM, Dominick Samperi wrote:
> In case this is not obvious, I should also note that this is a ghci
> problem. When
> compiled using ghc 7.10.1 there are no probelms with unresolved reference
In case this is not obvious, I should also note that this is a ghci
problem. When
compiled using ghc 7.10.1 there are no probelms with unresolved references.
On Sat, Jun 27, 2015 at 9:07 AM, Dominick Samperi wrote:
> I've attached the output of ghc --info. Will have to work on
> craft
I've attached the output of ghc --info. Will have to work on
crafting a small example...
On Sat, Jun 27, 2015 at 8:16 AM, Sergei Trofimovich wrote:
> On Sat, 27 Jun 2015 07:59:33 -0400
> Dominick Samperi wrote:
>
>> To test ghci 7.10.1 I compiled from source and simply pla
askell/FFI
function is run the symbol is undefined.
On Sat, Jun 27, 2015 at 7:26 AM, Dominick Samperi wrote:
> Thank you, the 'ghci -v2' suggestion was helpful. I now see the
> expected link steps.
>
> But when I try to run there are unresolved symbols (with ghci 7.10.1;
>
10.1 under
Fedora 21. I'm using
the latest released HP with ghci 7.8.3.
To test ghci 7.10.1 I compiled from source and simply placed the
resulting bin in
my PATH. Perhaps this is not enough?
On Sat, Jun 27, 2015 at 6:01 AM, Sergei Trofimovich wrote:
> On Fri, 26 Jun 2015 23:05:55 -0400
Hello,
I'm trying to run code that works with ghci 7.8.3 under ghci 7.10.1
but this fails.
Under 7.8.3, when I run from the shell:
export LD_LIBRARY_PATH=thepath
ghci -lmylib -fno-ghci-sandbox mydriver.hs
I see the usual startup diagnostics along with
Loading object (dynamic) mylib ... done
fina
pandoc. Thanks to John MacFarlane (pandoc
author) for this tip.
On Sat, Jan 17, 2015 at 7:15 AM, Peter Trommler
wrote:
> Dominick Samperi wrote:
>
>> It turns out that the undefined reference to libHSprimitive-0.5.4.0.so
>> when installing pandoc is not related to the use o
libs are created, as in the build
for ghc-7.6.3?
On Sat, Jan 17, 2015 at 3:36 AM, Herbert Valerio Riedel
wrote:
> On 2015-01-17 at 09:22:05 +0100, Dominick Samperi wrote:
>> It turns out that the undefined reference to libHSprimitive-0.5.4.0.so
>> when installing pandoc is not
It turns out that the undefined reference to libHSprimitive-0.5.4.0.so
when installing pandoc is not related to the use of CentOS or Debian
binaries. I get the same undefined reference when I try to use
ghc-7.8.4 compiled from source under Fedora 21. Here is the output of
'locate libHSprimitive':
think.
Cheers,
Dominick
On Mon, Jan 12, 2015 at 3:34 AM, Roman Cheplyaka wrote:
> On 12/01/15 04:00, Dominick Samperi wrote:
>> Hi Roman.
>>
>> As I said in my comments I tried the binary distribution provided for
>> CentOS65 Linux but ran into problems. I also trie
Thank you Edward.
I managed to build from HEAD under Fedora 21 (after 'cabal install containers').
The errors I reported may be related to the way I tried to clone a particular
branch:
git clone -b ghc-7.8 git://github.com/ghc/ghc.git
It is not clear how to checkout/build/package a particular v
or: libHSprimitive-0.5.4.0.so (libHSprimitive-0.5.4.0.so:
cannot open shared object file: No such file or directory)
Failed to install vector-0.10.12.2
cabal: Error: some packages failed to install:
vector-0.10.12.2 failed during the building phase. The exception was:
ExitFailure 1
On Sun, Jan
Hello,
I'm trying to build ghc-7.8 branch under Fedora 21 and I get the
failure diagnostics appended below. The problem seems to be that the
build process cannot satisfy deepseq >=1.2 && <1.4, but I explicitly
installed deepseq-1.3.0.2, and this did not help (same error?).
Under Fedora 21 Haskell
Hello John,
I tried to install the Haskell demo Cube on my Nexus 7
and got: Error: package file was not signed correctly.
D
On Thu, Jul 3, 2014 at 4:47 PM, John Meacham wrote:
> In case anyone wanted to start writing haskell android code now, jhc
> fully supports android as a target. here is an a
Given the examples provided with this proposal it looks like this
change is targeted mostly at compiler hackers, and not at
library/package developers. For the latter community it would be nice
to establish a policy for libraries and packages that encourages
("nudges") developers to include comment
not affect how external C/C++ libs are linked to (using the
system linker). From other comments in this thread it
appears that there may be problems linking to C++ libs
that require static initialization.
On Mon, May 5, 2014 at 4:58 PM, Simon Marlow wrote:
> On 03/05/14 04:15, Dominick Samp
at 3:45 PM, Simon Marlow wrote:
> Can you give me a quick summary of how to reproduce the problem? (not
> including the GHC build steps)
>
> Cheers,
> Simon
>
>
> On 02/05/14 18:18, Dominick Samperi wrote:
>>
>> I downloaded HEAD and placed DYNAMIC_GHC_PROGRA
:45 PM, Simon Marlow wrote:
> Can you give me a quick summary of how to reproduce the problem? (not
> including the GHC build steps)
>
> Cheers,
> Simon
>
>
> On 02/05/14 18:18, Dominick Samperi wrote:
>>
>> I downloaded HEAD and placed DYNAMIC_GHC_PROGRAM
HC_PROGRAMS=YES is required to prevent the problems
reported by me and others.
On Fri, May 2, 2014 at 9:09 AM, Simon Marlow wrote:
> On 02/05/2014 01:09, Dominick Samperi wrote:
>
>> If I understand your last comment correctly linking to libR should
>> continue to work, even if
Thu, May 1, 2014 at 8:09 PM, Dominick Samperi wrote:
> It turns out that the 7.8 update fixed problems that were NOT
> fixed by using -fno-ghci-sandbox with earlier versions of ghci,
> like 7.6.3, so this flag by itself did not address the issue. I
> assumed (perhaps incorrectly)
at R is a C library, so the C++ issues that Carter mentions are
not a factor here.
Thanks,
Dominick
On Thu, May 1, 2014 at 5:27 PM, Simon Marlow wrote:
> On 01/05/14 14:48, Dominick Samperi wrote:
>>
>> The problem with some graphics libraries used via FFI (and other libraries
>
The problem with some graphics libraries used via FFI (and other libraries
that are not thread-safe), if I understand the situation correctly, is that ghci
forks a thread when it shouldn't, causing some programs to miscalculate
the available stack space (because they think there is only one thread)
This was my error, sorry. The work-around is fine for 7.8.2.
The last remark still applies: it is not apparent how to
reset passwords on the issue tracker site.
On Sun, Apr 13, 2014 at 3:43 PM, Dominick Samperi wrote:
> I ticket #8371 I reported a problem using embedded R with ghci (no prob
I ticket #8371 I reported a problem using embedded R with ghci (no problem
when application is compiled with ghc). The work-around was to use
the option -fno-ghci-sandbox with ghci, as this prevented ghci from starting
a new thread (R is not thread-safe).
This worked fine with pre-release ghci 7.7
Thanks Luke!
Tested on simulator and device, and both work.
The docs need a few more comments, namely, users should
download the latest ghc-ios-scripts as these have changed,
and the output files Counter.a and Counter_stub.h are now
written to subdirectories build/i386 and build/arm for the
respe
SObject category with a + (void)load { hs_init(NULL,
> NULL) } method, which will ensure hs_init is called very early in your
> program and then you don't have to worry about it anymore.)
>
> Thanks so much for testing!
> Cheers
> Luke
>
>
> On Wed, Feb 5, 2014 at
ctions on how to create fat
> libraries that contain both simulator and device code.
>
> Please let me know if you have any questions or issues!
>
> Very best
> Luke
>
>
> On Tue, Feb 4, 2014 at 11:35 PM, Dominick Samperi
> wrote:
>>
>> Hello Luke,
>>
Hello Luke,
It installed without problems under Mac OS X Mavericks and reports the
version correctly. If there is some documentation that you can point me to
I will test on my simulator and iPhone.
Thanks,
Dominick
On Wed, Feb 5, 2014 at 1:36 AM, Luke Iannini wrote:
> Hi all,
>
> I believe I'v
That is great Luke,
I hope your work gets rolled into 7.8.
Is this just "experimental," or is it possible to actually develop
an app that will pass Apple's QA and can be hosted on the
app store? Are there any examples currently hosted on the App Store?
Thanks,
Dominick
On Wed, Jan 29, 2014 at
Will this work with the new iPhone 5 S (64 bit ARM)? I assume that
it will work by running in 32 bit mode (requiring both 64 and 32 bit
libs to be loaded), but I'm not sure...
Thanks,
Dominick
On Mon, Oct 14, 2013 at 3:48 PM, Luke Iannini wrote:
> Hi all,
>
> Just wanted to let you know I've f
, potentially showing comments
out of context. Sorry.
Dominick
On Sat, Sep 28, 2013 at 10:35 AM, Dominick Samperi wrote:
> After further testing it appears this work-around is not enough.
> It needs to be combined with another suggestion in this
> thread: must use ghc-7.7. There is a segfault (bu
After further testing it appears this work-around is not enough.
It needs to be combined with another suggestion in this
thread: must use ghc-7.7. There is a segfault (but no
"C stack usage" message) when ghc-7.6.3 is used.
Thank you!
On Sat, Sep 28, 2013 at 10:08 AM, Dominick Sam
Thanks! Turning off R's stack limit checks will not work. I tried this
and this leads to a segfault. Fortunately, your experiments led me
to a work-around: simply use the -fno-ghci-sandbox flag.
R is not thread-safe, and this flag tells ghci to run computations
in the main thread instead of forkin
Apple has kept their 64-bit plans secret until recently, but now they want
as many apps as possible to migrate to 64-bit. That may mean a big push for
64-bit support in LLVM, which can be built upon by GHC...
On Sep 23, 2013 1:06 PM, "Karel Gardas" wrote:
> On 09/23/13 06:52 PM, Dom
Cheers
> Luke
>
> On Sep 3, 2013, at 6:18 PM, Dominick Samperi wrote:
>
> Hi Luke,
>
> Thanks for your help!
>
> I managed to build (after checking out the snapshot that you
> mentioned), successfully generated haskell.a, and
> it worked on my simulator. There wa
ld environment is? (OS
> version, Xcode version etc)
>
> Cheers
> Luke
>
>
> On Sun, Sep 1, 2013 at 4:32 PM, Dominick Samperi wrote:
>
>> Hi,
>>
>> I followed the instructions on the link, downloaded ghc, created build.mk,
>> etc.,
>> and conf
Hi,
I followed the instructions on the link, downloaded ghc, created build.mk,
etc.,
and configured for ghc-ios-sim. But the make fails with the message below.
Tried installing terminfo (cabal install terminfo) but this didn't help...
ghc $ make
===--- building phase 0
make -r --no-print-director
57 matches
Mail list logo