I'm maintaining this package on Anaconda: https://anaconda.org/jetbrains/kotlin-jupyter-kernel
There are two different "latest" versions.
The correct one (0.8.3.64) is displayed here:
Another one (0.8.3.1) is displayed here:
Both versions were uploaded the same way, and I have no idea about this kind of diverge.
There are also two Anaconda badges that seem to use differend ways of getting latest version.
First one: https://anaconda.org/jetbrains/kotlin-jupyter-kernel/badges/version.svg
Second one: https://img.shields.io/conda/v/jetbrains/kotlin-jupyter-kernel?label=Anaconda
It seems to be a bug, but I haven't found a place to report it. So, I'm placing it here - you're welcome to point out the thing where I'm wrong.
Related
Recently we upgraded our SONAR from 3.x to 4.3. There was an error in our Jenkins build (squidindex was null) which triggered the upgrade of the java from 2.2 to 2.2.1 along with the plugins for JaCoCo, Findbugs, Squid for Java, and Surefire.
Once SonarQube was up and running again, we discovered that although no code changes had taken place, we now had over 200 critical issues as well as a high number of major ones. Upon research, it became apparent that all of our previously marked false-positives had now reappeared.
Obviously we want to find a way to fix this besides walking through over a thousand various issues and re-marking them.
We have done some research in the database and have discovered a puzzle that we think might be related. In the Issues table, we have found that there are duplicate entries where the first difference is that one entry has the simple file name and the other entry has the file name along with the extension.
(I had an image of a few lines from the database to put here, but as I do not yet have a 10 reputation, I cannot. Please contact me and I will be glad to email the image. Sigh.)
As you can see, Lines 2 & 3 both refer to line 134 in the file PersistentObjectCollection.java. Line 2 shows that the issue is FIXED and CLOSED while Line 3 shows the same issue as Open and null resolution.
We are wondering if we could safely use SQL to find matched pairs like this and copy the necessary columns across to register the issues properly?
Can you please take a look and tell me if this is something feasible to do, or if there is a better alternative to try.
Question already asked on the SonarQube mailing list : http://sonar.markmail.org/thread/kpx3une24lwoilli
Please don't duplicate question !!
I've succesfully generated a docset with AppleDoc by following the installation instructions. If i got into XCode Documentation Organiser, everything is there, including the categories:
But when I ⌥-click on one of my category methods I see nothing but this:
I've tried a lot of things but none of these work:
Adding --no-merge-categories
Adding --merge-categories
Changing filename extensions
Restart XCode
Restart macbook
Search google (AppleDoc quickhelp categories)
Search stackoverflow
Search gitHub repository issue list (https://github.com/tomaz/appledoc)
Please help, because I want to generate documentation, and most of my library consists of categories. I'm using the latest AppleDoc (appledoc 2.1 (build 858)), and Xcode 4.6.3.
Edit: are there users actually using AppleDoc? Does the quick help actually work for you? I also note a lack of documentation even though the repository is updated regularly.
It seems nobody else is using appledoc but me. Anyway, it looks like it is a bug in XCode, i have pushed a workaround in github. Comment if you want details.
Update: my pull request has been accepted, check here for details:
Pull request https://github.com/tomaz/appledoc/pull/375
related issue: https://github.com/tomaz/appledoc/issues/374
I have this posted here:
https://getsatisfaction.com/pixelandtonic/topics/wygwam_not_styled_in_cp_entry_and_not_functioning_shown_errors_attached
...but I really need a fix asap if anyone can help here.
I can't get Wygwam to work.
It started with me running this:
EE 1.6.8 (Again, can't update)
Wygwam 2.1.6
FieldFrames 1.4.5
I wasn't able to activate the module. I would receive errors and then the field was jacked.
I then upgraded Wygwam to 2.6.3 and that allowed my to enable the module.
The problem I have now is this:
When I try to Add a new Wygwam field, it tells me that there are no configurations available. When I go to 'Edit Configurations', I only get the serial number input field. I added the serial number, but nothing changed. Under 'Editor Configurations' it just says: There are currently no configurations.
Now I have the existing fields back, however, I cannot view source and do not have any "Configurable Editors" available. I also cannot setup any "Configurable Editors" in the module because I have no settings/options display. Also, I cannot add any new Wygwam fields because when I do, I just get a white screen.
Ok, While this may not be the best answer to provide, it has provided a resolve to the situation I was in.
First off, Kudos goes to Brad Bell at Pixel & Tonic for sticking with me via emails in trying to get this fixed. I am in a situation with this site in which I can't provide access to the site, files, data, etc. It definitely makes getting help with EE related instances more difficult. Brandon and his staff definitely know how to push through these issues.
Thanks guys.
Nothing we were trying was working. What I had to end up doing was rolling back the versions of Wygwam and Matrix from the more recent releases that were installed to WW 2.1.1 and Matrix 2.0.11
I didn't try newer versions as I want to push harder than ever now for a site update/rebuild due to these issues and others. The site is again functional in these areas and they can move forward, (or laterally... depending on your stance), again.
Asked this on superuser.com, not sure if stackoverflow is a better suitable place for it, but I am not getting any answers yet:
===
I am trying to generate a new blog entry in my octopress setup, but I noticed that some previous posts are being generated as empty files in public, so are the new ones I am trying to generte.
There seems to be no difference at all between the markup files from one entry which is being properly generated to another that isn't
I've got two octopress installations, one's working and this one I am talking about isn't, updates octopress on both, reinstalled bundle but no luck, files as atom.xml are also not being generated correctly.
Also updated from ruby 1.9.2p290 to latest release from 1.9.3 but also did not difference.
Anyone's encountered this before?
===
This is most likely because you started using codeblocks. This was happening to me, and even posts/pages that didn't use codeblocks would fail to generate. My problem (on Windows) was that I didn't even have Python installed (thought I did). Installing it fixed the problem, then gave me another error, which was fixed by updating the pygments.rb (note .rb) gem. Doing these two things fixed all my problems.
There's a similar issue if you're on arch linux which defaults python to version 3 which isn't supported by pygments.rb yet. You'll have to look around to figure out how to fix that to use 2.7 instead, but it should be pretty straightforward.
Can you provide an example of: a) a post that doesn't generate correctly, and b) a post that does generate correctly?
I assume they are just individual posts (and not, for example, pages like /about/). I would also assume that they render as blank both in the blog index on your front page and on the individual post page.
Also - what does render? Is it rendering the rest of the page, but just without the "content" of the post itself? Or does the page not even exist? (404?)
I'm trying to
Install-Package NHibernate
but I'm getting "Package ... could not be found". If I open the PCM-options, the list of available sources is filled, but the green OK-symbol isn't there.
Can I use an alternative source different to the MS-Links-ID 206669 which is the default source in VS?
I had a similar problem last night. The two LinkID values I had were:
206669 and 19913
Meaning that the URL I pass into the Settings dialog were:
https://go.microsoft.com/fwlink/?LinkID=206669
https://go.microsoft.com/fwlink/?LinkID=19913
The 19913 did not yield anything in the list of packages available. I think this number came when I installed the package a few weeks (months?) ago and gave up the first time.
The 206669 seemed to work. I could see the expected packages, but I could only install some packages, not all. For example, I could get Castle, but not Log4net. I could get AutoMapper, but not RestSharp. The ones that failed simply said "operation timeout".
I'm glad that I'm not the only one to see these issues - I did not see anything about this in the FAQs or documentation.
It seems that the LinkID and that URL are a weakness in the framework. I would like to see more discussion about that these values mean, and why there seem to be now at least 3 different values to use. How about a more clear link like www.nuget.com?
And how about a message showing more clearly why an operation times out on one package but not another.
NuGet has great promise, and many people swear by it. I want to get on board, but hiccups like this can really stop people from adopting it.
Cheers,
Daniel