I do not understand why RePEc:hem:wpaper:0702 disappeared from the account
of karine.lamiraud(a)unil.ch. And I do not seem to be able to add it back
in.
Christian Zimmermann FIGUGEGL!
Department of Economics
University of Connecticut
341 Mansfield Road, Unit 1063
Storrs, CT 06269-1063
http://ideas.repec.org/zimm/ christian.zimmermann(a)uconn.edu
http://ideas.repec.org/e/pzi1.html
---------- Forwarded message ----------
Date: Sat, 8 Aug 2009 09:29:18 -0400
From: "Karine.Lamiraud(a)unil.ch" <Karine.Lamiraud(a)unil.ch>
To: "Zimmermann, Christian" <christian.zimmermann(a)uconn.edu>
Subject: Re: question
Merci pour votre réponse, mais cette procédure ne
fonctionne pas. je ne comprends pas parce que ce WP était
avant dans mon profil et il a disparu de la liste de mes
travaux et n'apparait plus dans mes statistiques (alors
qu'il apparait chez mes coauteurs). Comment pouvons-nous
faire?
Bien cordialement,
Karine Lamiraud
----- Original Message -----
Expéditeur: Christian Zimmermann
<christian.zimmermann(a)uconn.edu>
à: "Karine.Lamiraud(a)unil.ch" <Karine.Lamiraud(a)unil.ch>
Sujet: Re: question
Date: Wed, 5 Aug 2009 13:14:49 -0400 (EDT)
> Entrez dans http://authors.repec.org/, clicquez sur
> "research" puis ajoutez la papier a votre profil.
>
> Christian Zimmermann
> FIGUGEGL! Department of Economics
> University of Connecticut
> 341 Mansfield Road, Unit 1063
> Storrs, CT 06269-1063
> http://ideas.repec.org/zimm/
> christian.zimmermann(a)uconn.edu
> http://ideas.repec.org/e/pzi1.html
>
> On Wed, 5 Aug 2009, Karine.Lamiraud(a)unil.ch wrote:
>
>> Hello,
>>
>> Could you help me on the following problem :
>>
>> My research paper entitled
>>
>> "Brigitte Dormont & Pierre-Yves Geoffard & Karine
>> Lamiraud, 2007. "The influence of supplementary health
>> insurance on switching behaviour : evidence on Swiss
>> data," Working Papers 0702, University of Lausanne,
>> Institute of Health Economics and Management (IEMS)"
>>
>> no longer apperas in my statistics. I have another
>> version of this paper which appears (PSE WP) but this
>> one no longer shows up in my statistics.
>>
>> Best,
>> Karine Lamiraud
>>
>>
>>
People getting automatic suggestions by email typically get in their
message a line like:
"BTW, you still have 104 other documents which were found earlier but
still wait for your decision. See them on your Research profile's
automatic search suggestions page." (example from attached message)
After getting some complaints from users that could not find the promsed
works, I have monitored those that bounce, and I not found a single
instance where this number was right. In this particular case, it should
107.
I could not find a systematic error. Sometimes, it is too high, sometimes
too low. But it is never lower than the number of items directly suggested
in the message.
I have also added this to my RAS wish list at
http://ideas.repec.org/zimm/personal/raswish.html. Note that I have been
maintaining this list for years, yet not a single item has been dealt
with. I find this very sad, and frustrating, as these are all suggestions
coming from the actual use of the product, i.e., consumer tested. I have
even added priorities to the items so that one can figure out what is more
urgent.
Christian Zimmermann FIGUGEGL!
Department of Economics
University of Connecticut
341 Mansfield Road, Unit 1063
Storrs, CT 06269-1063
http://ideas.repec.org/zimm/ christian.zimmermann(a)uconn.edu
http://ideas.repec.org/e/pzi1.html
---------- Forwarded message ----------
Date: Fri, 14 Aug 2009 07:16:50 -0400
From: Internet Mail Delivery <postmaster(a)correo1.ident.uniovi.es>
To: "Zimmermann, Christian" <christian.zimmermann(a)uconn.edu>
Subject: Undeliverable: [RePEc] automatic research profile update
Delivery has failed to these recipients or distribution lists:
anaj(a)uniovi.es<mailto:anaj@uniovi.es>
An error occurred while trying to deliver this message to the recipient's e-mail address. Microsoft Exchange will not try to redeliver this message for you. Please try resending this message, or provide the following diagnostic text to your system administrator.
Diagnostic information for administrators:
Generating server: correo1.ident.uniovi.es (ims-ms-daemon)
anaj(a)uniovi.es
#< #5.0.0> #SMTP#
Original message headers:
Return-Path: <aras(a)authors.repec.org>
Received: from ims-ms-daemon.correo1.ident.uniovi.es by
correo1.ident.uniovi.es (UNIVERSIDAD DE OVIEDO) id
<0KOD00J4I5ZSCU00(a)correo1.ident.uniovi.es>; Fri, 14 Aug 2009 13:16:40 +0200
(CEST)
Received: from correo1.si.uniovi.es ([172.30.1.75]) by correo1.ident.uniovi.es
(UNIVERSIDAD DE OVIEDO)
with ESMTP id <0KOD0058T5ZSMN60(a)correo1.ident.uniovi.es> for anaj(a)uniovi.es;
Fri, 14 Aug 2009 13:16:40 +0200 (CEST)
Received: from XANES.NET.UNIOVI.ES ([156.35.11.6])
by correo1.si.uniovi.es (UNIVERSIDAD DE OVIEDO)
with ESMTP id <0KOD00L8F5ZSVE90(a)correo1.si.uniovi.es> for anaj(a)uniovi.es
(ORCPT anaj(a)uniovi.es) Fri, 14 Aug 2009 13:16:40 +0200 (CEST)
Received: from CONVERSION-DAEMON.xanes.net.uniovi.es by xanes.net.uniovi.es
(PMDF V6.4 #31672) id <01NCIIH32BZK006KEU(a)xanes.net.uniovi.es> for
anaj(a)uniovi.es; Fri, 14 Aug 2009 13:16:40 +0200 (CET)
Received: from nebka.uconn.edu (nebka.uconn.edu [137.99.31.70])
by xanes.net.uniovi.es (PMDF V6.4 #31672)
with ESMTP id <01NCIIGXZ0YQ006KFP(a)xanes.net.uniovi.es> for anaj(a)uniovi.es;
Fri, 14 Aug 2009 13:16:40 +0200 (CET)
Received: from aras by nebka.uconn.edu with local (Exim 4.69)
(envelope-from <aras(a)authors.repec.org>)
id 1Mbuls-0007En-9o for anaj(a)uniovi.es; Fri, 14 Aug 2009 07:16:32 -0400
Date: Fri, 14 Aug 2009 07:16:32 -0400
From: RePEc Author Service <authors(a)repec.org>
Subject: [RePEc] automatic research profile update
To: =?UTF-8?Q?Ana=20Jes=C3=BAs=20L=C3=B3pez?= <anaj(a)uniovi.es>
Message-ID: <E1Mbuls-0007En-9o(a)nebka.uconn.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Received-SPF: pass (uniovi.es: domain of authors.repec.org designates
137.99.31.70 as permitted sender) client-ip=137.99.31.70;
envelope-from=aras(a)authors.repec.org;
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: aras(a)authors.repec.org
X-SA-Exim-Scanned: No (on nebka.uconn.edu) SAEximRunCond expanded to false
Kit Baum writes
> "The software is not done until the documentation is done"...
>
> Seems that this adage was ignored in the project definition.
The software is documented, but the code is not.
Cheers,
Thomas Krichel http://openlib.org/home/krichel
RePEc:per:1965-06-05:thomas_krichel
skype: thomaskrichel
Some authors are getting frustrated because they are not finding some of
their works for the following reason: Some templates have HTML encoded
accents and such. As ACIS is treating everything as UTF-8, it does not
recognize these encodings and cannot find a match with name variations.
The solution, I think, is to preprocess the entering template with a HTML
to UTF-8 filter. I have previously suggested on repec-run to include such
a filter in ReDIF-perl, but Thomas suggest this should be done by the
services individually. As RAS is by far the one suffering the most from
this problem, I thus ask that this be done.
I have added this to my RAS wish list:
http://ideas.repec.org/zimm/personal/raswish.html
Christian Zimmermann FIGUGEGL!
Department of Economics
University of Connecticut
341 Mansfield Road, Unit 1063
Storrs, CT 06269-1063
http://ideas.repec.org/zimm/ christian.zimmermann(a)uconn.edu
http://ideas.repec.org/e/pzi1.html
The problem with Barro is still with us.
Mon Jul 13 23:11:37 2009 request:
source: /home/aras/acis/bin/updareq [17370]
collection: ACIS
update: /r/b/rbarro(a)harvard.edu.xml ()
U DATAFILE_START: r/b/rbarro(a)harvard.edu.xml
RECORD OLD: rbarro(a)harvard.edu
Mon Jul 13 23:11:49 2009 Error: cannot store record 'repec:per:2005-04-12:robert_j_barro' in ObjectDB at /home/aras/acis/lib/ARDB.pm line 190.
Barro and Heckman (the other case) are large
aras@nebka:~$ ls -l acis/userdata/r/b/rbarro\(a)harvard.edu.xml
-rw-r--r-- 1 aras aras 6165312 2009-07-10 16:53 acis/userdata/r/b/rbarro(a)harvard.edu.xml
I suspect there is some size limitation that we are hitting.
Cheers,
Thomas Krichel http://openlib.org/home/krichel
RePEc:per:1965-06-05:thomas_krichel
skype: thomaskrichel
Thomas, revert this immediately. I am getting an avalanche of complaints
that the RePEc Author Service is not reachable anymore.
Christian Zimmermann FIGUGEGL!
Department of Economics
University of Connecticut
341 Mansfield Road, Unit 1063
Storrs, CT 06269-1063
http://ideas.repec.org/zimm/ christian.zimmermann(a)uconn.edu
http://ideas.repec.org/e/pzi1.html
On Mon, 20 Jul 2009, Thomas Krichel wrote:
>
> Give the troubles at fafner, I have moved services from
> that machine. The mailing lists and web services have gone
> to snefru. The aacis account has gone to nebka, where it
> used to be.
>
> Cheers,
>
> Thomas Krichel http://openlib.org/home/krichel
> RePEc:per:1965-06-05:thomas_krichel
> skype: thomaskrichel
>
> _______________________________________________
> ACIS-tech mailing list
> ACIS-tech(a)lists.openlib.org
> http://lists.openlib.org/mailman/listinfo/acis-tech
>
Thomas Krichel writes
>
>
> The problem with Barro is still with us.
>
> Mon Jul 13 23:11:37 2009 request:
> source: /home/aras/acis/bin/updareq [17370]
> collection: ACIS
> update: /r/b/rbarro(a)harvard.edu.xml ()
> U DATAFILE_START: r/b/rbarro(a)harvard.edu.xml
> RECORD OLD: rbarro(a)harvard.edu
> Mon Jul 13 23:11:49 2009 Error: cannot store record 'repec:per:2005-04-12:robert_j_barro' in ObjectDB at /home/aras/acis/lib/ARDB.pm line 190.
>
> Barro and Heckman (the other case) are large
>
> aras@nebka:~$ ls -l acis/userdata/r/b/rbarro\(a)harvard.edu.xml
> -rw-r--r-- 1 aras aras 6165312 2009-07-10 16:53 acis/userdata/r/b/rbarro(a)harvard.edu.xml
>
> I suspect there is some size limitation that we are hitting.
>
I don't think there is any limitation built in into ACIS, but
I read
http://www.mysql.com/news-and-events/newsletter/2003-09/a0000000237.html
The theoretical limit in MySQL 4.0 is 2G, however each blob requires generally to have 3 copies of it in the memory (stored in various buffers) so you need a lot of memory, if you have large BLOBs stored in MySQL. This is the reason, why the theoretical limit can be reached only on 64bit systems. The Practical limits are around some hundreds of megs per BLOB.
We need more memory, or we can just ignore this issue as the
blobs are not actually used?
Cheers,
Thomas Krichel http://openlib.org/home/krichel
RePEc:per:1965-06-05:thomas_krichel
skype: thomaskrichel
Ivan Kurmanov writes
> from what I saw in the logs excerpts you've shown, the database is
> corrupted in some way or another. Unless the db4.6_upgrade somehow
> fixed it all, i'd suggest to start with a clean database.
I have just run the script on the RePEc databases, since it
seems to have bee doing something good on the ACIS databases.
Cheers,
Thomas Krichel http://openlib.org/home/krichel
RePEc:per:1965-06-05:thomas_krichel
skype: thomaskrichel
