Long inline code within paragraph breaks formatting in PDF

I have an inline code in a paragraph like below in RST :
To verify the progress of the operation objects obtained in :ref:Step 1<Step 1: Upload CSV documents>, use the GET /v1/operations/ endpoint. We can conveniently pass the operation object IDs as query parameters to narrow its results. For example: GET /v1/operations/?id=<operation_obj_1_id>&id=<operation_obj_2_id>&...&id=<operation_obj_n_id>.
But, the PDF output for this line has too many white spaces:

I can use the codeblock, but I don't see using codeblock for a single line makes sense. There should be a way to fix this line-breaking issue from simplepdf style?

I think we need to fix some CSS here. But I'm not sure which rules, yet.
Also our DEMO-PDF has 1-2 examples, which are shown this problem.
Thanks for reporting it.


Change dummy docker image used in test

We are currently using the image nginx or nginx:latest as a dummy image to run some test with docker.
Today, nginx released a buggy image that could not start and thus break our tests.
To do:

[ ] We should use our own image
[ ] The image should be as small as possible
[ ] The image should be build in the CI or at least be hosted in a MESG repo
[ ] The image should be easily changed: suggestion: add it in a viper config

Here is some example where the nginx image is used:
https://github.com/mesg-foundation/core/blob/505fde73968a366ca6bf643eb9e85ce3603dadd0/service/start_test.go#L37
https://github.com/mesg-foundation/core/blob/505fde73968a366ca6bf643eb9e85ce3603dadd0/service/start_test.go#L54

@krhubert already created a very small image: https://github.com/krhubert/docker-sleep

@krhubert Could we build your docker-sleep image directly in the CI without any files?

meged


Ensure Action Update Creates a Web Action (Review)

Closes https://github.com/apache/incubator-openwhisk/issues/2428

@mdeuser, please review.

PG3 791.

PG approved.

@mdeuser, good catch. I made an update that should ensure that existing annotations are overwritten if new annotations with matching keys are provided. Modified the test accordingly.

@rabbah, recent a change went in that flipped the update flag to true for action updates (https://github.com/apache/incubator-openwhisk/commit/9c1f77fdb1e4a7339634434dc90c45026d6a43d2#diff-41c5935cb68718d73fa6ef611c927cc4R100). This enabled the ability to get action annotations that already exist and append new annotations to that list when updating a web action. However, preserving annotations that already exist is not a feature that is synced across commands (package update, trigger update, etc...). As per a conversation with @mdeuser, we are thinking about flipping the update flag back to flase so that the same update functionality is used across commands.

@mdeuser, @rabbah, the alternative here would be to always pass in a value of false into this line: https://github.com/apache/incubator-openwhisk/blob/master/tools/cli/go-whisk-cli/commands/action.go#L402.

@dubeejw i defer to you and mark as the go CLI experts.

bump
@akrabat hit this again in the field.
how can we move this one forward

What is here works and will fix the issue. Problem is that the action update command with the web flag specified will behave differently than a normal action update as it keeps all existing annotations that action has.

With the implementation from this PR action1 will have annotations for key1, key2 and the web annotations when the following commands are executed.
wsk action create action1 --annotation key1 value1
wsk action update action1 --web true --annotation key2 value2

Perhaps I should change the implementation to only preserve existing annotations only when the --web flag is specified and no addition annotations are provided.
That way the following would only have the web and key2 annotation.
wsk action create action1 --annotation key1 value1
wsk action update action1 --web true --annotation key2 value2
That way the following would have the web and key1 annotation.
wsk action create action1 --annotation key1 value1
wsk action update action1 --web true

@mdeuser, @rabbah, @csantanapr, thoughts on the above?

@dubeejw yes I think this is becoming to fix.
Let's implement like you suggested in https://github.com/apache/incubator-openwhisk/pull/2435#issuecomment-320044929
if --web present with other annotations being set in cmd line, only those annotations would be set. it would work like the other entity annotations.
if --web present and no annotations in cmd, then annotations are not touch only the export-web
this will unblock the bug, which I lot of people are using action update to provision

imho, i worry a bit about the semantics of "update" changing just because a particular command flag is used.

https://github.com/apache/incubator-openwhisk/pull/2435#issuecomment-320044929

@mdeuser I think what @dubeejw proposed and I understood was to leave the semantics the same as today.

PG2 1909 ⏳

@mdeuser, take another look. Made some updates to keep the current semantics in place.

This is interesting as --web is implemented as a set of annotations under-the-hood, but doesn't look like one to the user. It would be decidedly non-intuitive for wsk update action test test.js --web true to remove all other annotations as --web true doesn't look like you're dealing annotations.
What I would expect to happen:
1 wsk update action test test.js --web true : all current annotations are not touched
2 wsk update action test test.js --web true -a foo bar : all other annotations other than foo are removed
From my point of view, --web doesn't look like -a and so should not touch anything added with -a. My understanding of the conversation above is that this is what @dubeejw has implemented in this PR.

That's my understanding Rob and my desire also.
Can you confirm @dubeejw ?

@akrabat, @csantanapr, current code in the PR to has the described functionality. Just needs a final review. Feel free to test it out.

Probably not what this PR was wanting to remedy, but since this came up....

wsk update action test test.js --web true -a foo bar : all other annotations other than foo are removed
That behavior may change in the future to "only the annotation foo is updated/created; all other annotations are left as-is"

see also https://github.com/apache/incubator-openwhisk/issues/76

@mdeuser, any review comments?

PG3 975. ⏳

PG3 976 🔵 .

@mdeuser, anything else on this one?

Rebased for API experimental removal conflicts.


Create constants project to share between product and test code

We frequently have developer headaches when we update a string literal in the product code but forget to update it in the tests. This is particularly painful when the test only runs in the full functional test suite.
Create a new project full of constants that we can use across product and test code.

I understand the frustration here but my big concern would be leaking product code into the test code so that it is not isolated.  Functional tests should not know anything about the internals of the product so that the tests will fail if something in the product changes.  Strings might not be a big deal but what about utility methods that are the same in both?  And soon more and more of your code is in the shared project and bugs get through because the tests aren't in isolation.  I think this is more something that we need to learn.  When we change a string, search for it in tests.

I agree that we should be careful with what is shared, but this is not impossible to do safely.
I think this is the same idea as a compat layer between client and server. They need to be speaking the same language, even if they are formally separated.


User Settings

[x] Change Name
[x] Change Password

This should probably be its own form.
Removed 8/17/2021: Switched to OAuth.

[x] Select visible emails.

Removed 8/17/2021: We don't store emails in the database anymore.

[x] Change profile picture link

Removed 8/17/2021: Profile pictures are not supported.

[x] Add new email

This should probably be it's own form.
Removed 8/17/2021 (see above)

[ ] Link accounts

[ ] GitHub
[ ] Discord
[x] Mattermost
[x] RPI CAS

Done as of 0.6.4 (8/17/2021). Some issues perhaps:  #114

See #5

[x] Change bio

Removed 8/17/2021: User bios not supported in API.

Work in progress list of requirements. Subject to change.

Name, role, and cohort change functionality added 4d8207c83c98f9f999df87baec2caa3cc224f72e.

Closing this issue. Remaining functionality covered in #5.


fixed compressing 4+ gDNA plates issue

https://github.com/jdereus/LabControl/issues/488

@charles-cowart


Need to remove max_credits

Summary
Fix #4132
Details and comments
max_credits was deprecated

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@jakelishman Thank you for the review. I fixed the code based on your comments.

@jakelishman Any news for this PR?

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

14 of 15 (93.33%)  changed or added relevant lines in 7 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.01%) to 83.151%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit/test/mock/fake_qobj.py
0
1
0.0%

Files with Coverage Reduction
New Missed Lines
%

qiskit/utils/run_circuits.py
1
30.79%

Totals

Change from base Build<PHONE_NUMBER>:
0.01%

Covered Lines:
51999

Relevant Lines:
62536

💛  - Coveralls


Feature request: visualize the full scene in Build Mode (and a big thank you)

Hi.
First of all thanks a lot for releasing this essential plugin. I am just getting started with my project but from the beginning I realized even if gridmaps are very useful for my project, they are a pain to work with. I was coming from doing voxel based models with MagicaVoxel, and I was wondering why the gridmaps do not allow a similar way of building levels (MagicaVoxel allows building in a similar way to Minecraft). This solves that issue and it is beautifully implemented too (looking forward to those control styles since I am so used to the MagicaVoxel controls with E for fly upwards and Q for fly downwards).
In my specific case, but I imagine that it could be a common scenario, some levels will be fully build using a gridmap, but some other levels will use regular MeshInstance3D for the level structure and a gridmap for placing other blocks that are breakable, pickable or  decorative. The reason is performance. My game is a voxel based game, with small blocks and performance tanks with very big levels that might have a million blocks or so, but since I don't need any block to be destructible, I just make the base structure as a regular MeshInstance3D.

In this situation, if I use GridMap+ I will not be able to see that level structure, because is not part of the GridMap and I will be quite lost about where to place the blocks. If it was possible to see the full scene (just as it happens with Godot's built-in GridMap editor) this would be easy. Of course it could also lead to confusion, since the MeshInstance is not part of the GridMap and would not allow to place blocks attached to its geometry... but I think this could be solved by giving a couple of options like darken everything that is not the gridmap or a toggle to hide/show the rest of the scene.
Another situation where I think is useful is that I noticed that some projects prefer to use not one but two or more gridmaps to build a single level (as if in working with more than one layer) so they would also benefit from seeing the other gridmaps even if they can't interact with them).
I have no idea if this is possible or maybe very hard to do, so please take this as a suggestion and not a complaint about not being possible yet!
Another little thing I noticed is that (by a bad habbit) if I exit the editor doing ALT+F4 (in Windows) then the editor closes but Godot is kind of hang, without showing the mouse cursor, so I have to fully close Godot and open it again. It would be better if the plugin could capture the ALT+F4 order and maybe treat it as the same as pressing ESC (options to save or discard changes).
Thanks again!!

Thanks for using the plugin.
Allowing control customization is on the todo list, though I'm not sure when I'll get around to it. For now you can just alter the plugin code if you really need to change what controls it looks for. Fixing the Alt F4 is a good idea too.
Adding other level content is a great idea, I'm not sure exactly how I would go about doing that - maybe with another button that opens a tree allowing you to toggle which nodes you would like to duplicate. Perhaps a key could toggle it on and off. Holding multiple gridmaps and editing them as layers would be really sweet too. All of these need more specific scene management - at the moment the plugin just knows about the gridmap you clicked on, rather than being able to read/manipulate the whole scene. I haven't looked into how to do this, but it must be possible somehow.
I'm working on another project right now, but when I get some time I will look into these things. Tthe plugin is open source (gdscript) so feel free to tinker with it and if you get something useful, a PR is always appreciated.

As a first step, just being able to render the current scene (the same in which the GridMap node is on) and toggle it on/off would already probably cover most of use cases. Because even if the use case is having multiple GridMaps, you can always switch from one "layer" to another by closing the GridMap+ editor, selecting the other gridmap and entering the GridMap+ editor.
I am quite new to both Godot and game developer so I am not very confident of being able to do any useful PR, but if I happen to modify your plugin in a way that can help others, I will surely add a PR with the changes.
All the best with that other project and thank you for your reply.


[refactor] Introduce a dialect domain concept.

Language dialect is an important domain concept that should
be explicitly called out in code. It makes it much easier to
document it and makes code using it easier to follow, since
instead of true and false we use Dialect::Build or Dialect::Bzl.
This can also come very handy in case some useful methods should
be available for it.

Thanks for the quick review and useful suggestions, @damienmg!

And happy new year! :)

Thank you, @damienmg! You have a happy new year as well!


Splash Screen Improvements

I hope for 1.1 we can have some energy to pick this one back up again :)
On Android:

There should be no full-screen purple onscreen on its own
The branding element is not displayed for long enough - I can barely recognize it and it feels like a mistake.  Can we display on screen for 2 seconds?
The out-transition from the branding element to the landing screen is too abrupt.  It should fade.

On iOS:

Looks better!
The out-transition from the branding element to the landing screen should also be a fade.

I appreciate these feel small cosmetic issues.  But a splash screen forms the first impression, and currently it's undermining all the hard work that's gone into this app so far.
20200924-141323-720x1520.mp4.zip

Dupe


[BUG] Allow Epochs.compute_tfr() for the multitaper method and complex/phase outputs

Reference issue
Fixes #12831.
What does this implement/fix?
Fixes a bug where an internal check of the shape of TFR results was unexpectedly failing for results with both an epochs and tapers (multitaper method and complex/phase output) dimension.
Additional information
The check for whether an epochs dimension is present cannot rely on self._dims, as "epoch" only gets added afterwards, so it is instead based on the data passed in (i.e., is it an epochs object?). We don't have to worry about whether an epochs dimension is still present (e.g., if compute_tfr() was called with average=True), since average=True is not allowed when output="complex"/"phase".
There is currently no test checking the combination of multitaper method and complex/phase output, and I haven't added one here to avoid overburdening the test suite. If this is required I can add one.

There is currently no test checking the combination of multitaper method and complex/phase output, and I haven't added one here to avoid overburdening the test suite. If this is required I can add one.

Yes please do add it -- if the number of time points and channels is low it should be plenty fast, and it would be good to catch corner cases like this one!

Just added a very short test that multitaper complex/phase TFR runs.

Marking for merge-when-green, thanks in advance @tsbinns !

Seems some sklearn compliance checks are still failing.


Update web-sites-deploy.md

Corrected link for 'Deploying to Web Apps with GitHub using Kudu'.

Hi @TimMurphy, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no contribution license agreement is required at this point. Real humans will now evaluate your PR.

TTYL, AZPRBOT;


Symptoms section

Implementing the Symptoms sections minus the question about where the data was collected from until there is a component that can handle it.

This looks good! We should add the duplicating functionality to the specify other field, but that can come later (I also forgot to put it in my design).


Docs: rename 'PowerShell Core'. Closes #2620

Rename all PowerShell Core-references to PowerShell. Closes #2620

Mental note for reviewer, there has been some additional samples created after this PR. Before approving this PR please validate 'new' samples created after this and update accordingly.

@appieschot Did a quick check and I think only #2616 must be updated.


Push notifications not working the same way in dev (test) and prod (or ad hoc build)

I think, I have the same kind of problem when app is in prod, like #207 .
In Test (Dev mode): all is good.
Background Notification:
This is call first: (all meth in AppDelegate.m)
- (void)userNotificationCenter:(UNUserNotificationCenter *)center
       willPresentNotification:(UNNotification *)notification
         withCompletionHandler:(void (^)(UNNotificationPresentationOptions))completionHandler

(with: completionHandler(UNNotificationPresentationOptionAlert | UNNotificationPresentationOptionBadge | UNNotificationPresentationOptionSound);)
Then:
- (void)userNotificationCenter:(UNUserNotificationCenter *)center
didReceiveNotificationResponse:(UNNotificationResponse *)response
         withCompletionHandler:(void (^)())completionHandler

Foreground Notification:
Only the 2nd method:
- (void)userNotificationCenter:(UNUserNotificationCenter *)center
didReceiveNotificationResponse:(UNNotificationResponse *)response
         withCompletionHandler:(void (^)())completionHandler

In Prod (ad hoc): Not working as it should(?)
Background notification:
This method is called first:
- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo

(end with: [self application:application didReceiveRemoteNotification:userInfo fetchCompletionHandler:^(UIBackgroundFetchResult result) {}];)
then:
- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo
fetchCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler

Foreground Notification:
The 2nd method is called:
- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo
fetchCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler

So I added the follwing code to manage the notification in foreground (in the previous meth):
if (state == UIApplicationStateInactive || state == UIApplicationStateBackground) {
        // background
} else {
        // foreground -> display the notification like uiNotificationCenter
}

Why it's not working like in dev (test) ?
I know that it should work the same way in both dev en prod, but... I'm lost.
If it can help:
My config: FirebaseAppDelegateProxyEnabled = YES
I revoked my old certificate & keep the .p8 file.
My notification schema: (I only need the data part for ios, notification is for android)
{
	"to":"my InstanceID",
	"notification":
	{
		"click_action" : ".WebviewActivity",
		"body":"Test notification body",
		"title" : "Test notification title",
		"icon": "ic_stat_not"
	},
	"data" : {
		"message" : "Test data message",
		"AnotherActivity" : "false",
		"url": "my url",
		"body":"Test data body",
		"title" : "Test data title"
	},
	"priority":"high"
}

Also I have this 2 others method (if it can mess up....?)
- (void)userNotificationCenter:(UNUserNotificationCenter *)center
                   willPresent:(UNNotification *)notification
         withCompletionHandler:(void (^)(UNNotificationPresentationOptions))completionHandler

- (void)userNotificationCenter:(UNUserNotificationCenter *)center
                   willPresent:(UNNotification *)notification
         withCompletionHandler:(void (^)(UNNotificationPresentationOptions))completionHandler

Any clue?

Had similar problems. I have the Proxy set to NO, and I believe it does not have influence on if the notifications getting delivered.
 Make sure the node env is set to production.
One thing you didn't post here is how you set APNS tokens, which is a difference for development and production. In swift this looks like this:
func application(_ application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) {
        print("APNs token retrieved: \(deviceToken)")
        InstanceID.instanceID().setAPNSToken(deviceToken, type: .unknown)
}

.unkown will figure out itself which tokens to use, works fine for me.

Hi,
I'm sending notifications from octoberCMS (php) and the config is in test but I'm not sure this make a difference.  For the settings of the APNS tokens, I think I don't need it with Proxy set to YES.

If you have disabled method swizzling, you'll need to explicitly map your APNs token to the FCM registration token. Override the methods didRegisterForRemoteNotificationsWithDeviceToken to retrieve the APNs token, and then call setAPNSToken.

But I will reverse my settings and try Proxy to NO. Thx.


Stuck on "Status: Unknown" with no notifications - MacOS 13.4.1, Spotify

MacOS Version: 13.4.1
Spotify Version: Spotify for macOS (Apple Silicon) <IP_ADDRESS>1.gbf202593
I just installed Notify (not sure how to grab the version of it) and when I change songs in spotify, I get no notification, and the status on the tray icon just shows 'Status: Unknown'. Any way I can fix it (or get more info to help debug it)?

I'm having the same issue. I did not receive the dialogue box asking for permission for Spotify to use it either.
MacOS Version: 13.6
Spotify Version: <IP_ADDRESS>8.g02aff7a4

Same issue for me
macOS 13.5
Spotify for macOS (Apple Silicon) <IP_ADDRESS>8.g02aff7a4

I'm sorry for a late response. I'll take a look at the issue.

I'm sorry for a late response. I'll take a look at the issue.

Any news ?

I have a hard time reproducing the issue. Is the permissions settings green in Notify settings?

I don't see that in my settings window:

But I do have notification permissions granted:

However, I do not see Notify under Privacy and Security > Automation:

@asyncmeow What worked for me was to install it via brew. I first made sure the ".app" from the website is removed and then did a quick brew install and it worked flawlessly. :)
brew tap nahive/spotify-notify
brew install --cask spotify-notify --no-quarantine

Give that a go, it should help.

Thanks @berkiyo the brew tap solution works perfectly!
This issue does happen in the downloaded version from the website though. So it might be worth updating the installation instructions with the ones you have.

I can't grant automation permission. I installed it through brew and through the app, the result was the same.
Notify: 0.4.4
Sonoma: 14.3.1

*in the screenshot the automation section is open.

Thank you all for the help and sorry for being so late. I've released new version, let me know if that fixes the issues.
https://github.com/nahive/spotify-notify/releases/tag/0.5
@MilanovaSmile
Im not sure, but are you sure you have permissions to do automations?
You can also try running the command to reset the permissions and rerun the app.
tccutil reset All io.nahive.SpotifyNotify

I'm not sure why downloading directly from the website is not working. I'll take a closer look.

@nahive The new version didn't work. The problem is exactly the same. The app tells me: "Missing required automation permissions". I click "Go to Settings". The automation section opens in the settings, but it is empty.

@MilanovaSmile
Have you tried resetting the permissions with the command?

@MilanovaSmile
Are you allowed to give automation permissions on tour computer you're using?
Other than that I'm stumped. I'd love more diagnostics. The accessibility control is still buggy in macOS sadly.

Yes, I'm an administrator. What else can I do?

@MilanovaSmile
sorry for the late update. I've updated the logic. please take a look if that helps.
https://github.com/nahive/spotify-notify/releases/tag/0.5.1


Set the capacity of clientChan to 10000

What problem are we solving?
Setting the capacity of clientChan to 100 is too conservative; it will block jobs like KeepConnected/SendHeartbeat/ProcessGrowRequest when a large number of events occur.
How are we solving the problem?
Set the capacity of clientChan to 10000
How is the PR tested?
Checks

[ ] I have added unit tests if possible.
[ ] I will add related wiki document changes and link to this PR after merging.

with https://github.com/seaweedfs/seaweedfs/pull/5639 this seems not necessary?

with #5639 this seems not necessary?

This PR resolves the deadlock issue, but if the capacity of the channel is too small and the consum is too slow, wouldn't it block these jobs for a while?


fix: allow open to run async on linux

The whole function is already async, so it would make sense to be able to open a file without blocking. Unluckily, this small fix only works if the linuxByProcess flag is true.

@lexxxel
A new version including your fix is now published to the pub.dev
Sorry for the delay, I was busy last year and couldn't make it
Thanks for your efforts on this PR


Update macos image from 11 to latest

API change check
API changes are not detected in this pull request.

/azp run net - eng-script-tests

mgmt - ci failures are unrelated so override those for this change.


adding some code for stack and queue in python

code example for queue and stack implementation in python
[x] following rule
[x] Only implement algorithms that are already in the AAA
[x] only one language and one algorithm
[x] already test my code

@Amaras please review my code and can it be used?

[lang: python]

What is the state of this PR? I think there are a few lingering changes to be made, but after that, we now have code for stacks and queues, so this can probably be merged in


Fixed release arg typo and added repository to Cargo.toml

Thanks! I forgot to add a license… Could you rebase your branch on master to accept it?

@phil-opp Done!

Thanks a lot!


Update how-to-install-iot-edge-kubernetes.md

Fixed typo.

@auyidi1 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@PatAltimore
Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

Hi @auyidi1 ,
Thanks for the fix. Looks good.
Thanks,
Pat
#sign-off


Review @brightside usages for GA

For Zowe GA, we need to review leftover Brightside mentions within Zowe CLI and Zowe CLI Installation Doc, and prioritize resolution of them with target dates.

Known areas:
-Environment Variables
-Local Directory Usage (Home dir ".brightside")
-npm install comands (CA Bintray)
-npm install commands (@brightside scope)
-source tree package names (brightside)

I was talking with Bruce today and I’d like some input for GA.  With the teams running their own architecture discussions I know for me its hard to chase all of the content.  As Sean said, we probably shouldn’t have to but I have a sneaking suspicion that the GA 1 target is not universally defined.
One approach is to create the “press release” of what we are planning in delivering as Zowe Release <IP_ADDRESS> that outlines the capabilities, requirements, etc. and then the individual squads can ensure that their efforts are lining up with the technical capabilities of the formal release.  Other suggestions on how to unify the groups ?
We can take a swag at the initial release to put a “bird in the air” for everyone to look at, modify and come to consensus on.

On Sep 12, 2018, at 1:52 PM, Mark Ackert<EMAIL_ADDRESS>wrote:
For Zowe GA, we need to review leftover Brightside mentions within Zowe CLI and Zowe CLI Installation Doc, and prioritize resolution of them with target dates.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/zowe/zlc/issues/28, or mute the thread https://github.com/notifications/unsubscribe-auth/ACxXp6ABz50tXAgUijEjB6OudwGCs5umks5uaUnTgaJpZM4Wl3-a.

Matt, As you say - I think the teams are in varying states of planning and prioritization towards a GA 1 target.
Building on your idea for a "swag" of the initial release - I think we should take the following steps to consolidate our understanding and guidance for the teams:

Define high level objectives for Zowe GA 1 release at the ZLC level, prioritized by importance. Input from those outside the ZLC - marketing and technical - is welcome and desired.
Review squad backlogs w/ squad leads. Prioritize the work present in accordance with our high level objectives and their self-driven goals.

Once those two steps are done, we can evaluate our deliverable state / confidence and adjust our GA 1 goals or work items as necessary. Repeat step 2 as necessary.
I don't know that this will work out perfectly as some work is still in planning phase so we don't have a strong concept for the amount of time it will take to complete. I'm also a little conflicted over the defining of ZLC Zowe GA 1 goals as opposed to self-organizing squad goals, but we should start project guidance somewhere.

@1000TurquoisePogs @hogstrom @armstro @jplinardon
This Github issue went slightly off the rails from its intended purpose. Could we review this specific topic from this github issue on tomorrow's ZLC call:
-CLI npm install commands (@brightside scope)
We need to decide if changing the npm scope from @brightside to @zowe (or @zowecli) is something we see as being on the critical path for Zowe.
-@brightside/imperative -> @zowe/imperative
-@brightside/core -> @zowe/core
The work involved to change the scope and mitigate breakage periods is nontrivial, and will become more difficult as we defer it.

It's likely that at some point some zlux components will also be npm-installable. The widgets already can be pulled in from that way: https://github.com/zowe/zlux-widgets/blob/master/README.md
So, when it comes to "core" code, brightside's core is different from the ui core (zlux-platform and zlux-app-manager today). I'd use a more descriptive term than @zowe/core for this reason. @zowe/cli-core? @zowe-cli/core?

@zowe/zlc @jmertic
Matt & Sean & ZLC - When last we spoke on the ZLC call, I believe we said it would be preferable to change the CLI package name from @brightside/core to @zowe-cli/core by Zowe GA 1.0. After speaking with the team, they don't have capacity to complete this work by GA. The package naming change may even be postponed further in the future when prioritized against other features/epics in the pipeline - in other words - there is no estimated completion date after GA 1.0.
If the ZLC considers this work to be necessary for completion by GA time or afterwards, I believe the ZLC will need to vote to make it an official requirement which will trigger a re-prioritization of planned work by the CLI Squad. If this is the path we want to take, I will abstain from voting.

My gut is delaying this will cause more problems down the road than making the change now, as well as the confusion on mark usage ( unless CA wants to donate the brightside marks to the project ).

Saw this was discussed - what are next steps. I think it will be not ideal to have the brightside marks in the Zowe open source project code if that is a mark only being used by CA.

We were not able to discuss this topic on this week’s ZLC call, my request for discussion was sent out after the weekly call.
I think the ZLC needs to discuss/vote on the following two points

Mandate if the work needs to be completed
If (1) passes vote, then declare a timeframe for completion. 1.0.0 or can it be pushed after 1.0.0?

From: John Mertic<EMAIL_ADDRESS>Sent: Friday, October 26, 2018 9:03 AM
To: zowe/zlc<EMAIL_ADDRESS>Cc: Ackert, Mark G<EMAIL_ADDRESS>Assign<EMAIL_ADDRESS>Subject: Re: [zowe/zlc] Review @brightside usages for GA (#28)
CAUTION: This email originated from outside of CA. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Saw this was discussed - what are next steps. I think it will be not ideal to have the brightside marks in the Zowe open source project code if that is a mark only being used by CA.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_zowe_zlc_issues_28-23issuecomment-2D433399820&d=DwMCaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=vQmyJ3cryI0pp-72rN6D25sHuAlsustGo1A1CO3U-6A&m=ypnOkhM-AA_pMByez3RIxc3WfHm34nTd7EMbCEyxnAw&s=J_mAIygqZaKFDmJvMaa5anJQu2YpC-ct-g0nj8ecPa0&e=, or mute the threadhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AhrFpmY3X6CYhq3NkGfsZRzd4s-5FLglxvks5uowfrgaJpZM4Wl3-2Da&d=DwMCaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=vQmyJ3cryI0pp-72rN6D25sHuAlsustGo1A1CO3U-6A&m=ypnOkhM-AA_pMByez3RIxc3WfHm34nTd7EMbCEyxnAw&s=MeJ4HAKa9ks2HYdPufedFVvF1by027R2NWVXiFML0Rs&e=.

I’ll add that to the agenda.  I agree on owner, action, date and followup.
Matt Hogstrom
<EMAIL_ADDRESS>+1-919-656-0564
PGP Key: 0x90ECB270
Facebook https://www.facebook.com/matt.hogstrom  LinkedIn https://linkedin.com/in/mhogstrom  Twitter https://twitter.com/hogstrom
From Lord of the Rings, when Frodo decides to leave the Fellowship and go to Mordor alone . . . Frodo:  “I wish the ring had never come to me.  I wish none of this had happened.”  Gandalf:  “So do all who live to see such things.  But it is not for them to decide.  All you have to do is decide what to do with this time that is given to you.”

On Oct 26, 2018, at 2:28 PM, Mark Ackert<EMAIL_ADDRESS>wrote:
We were not able to discuss this topic on this week’s ZLC call, my request for discussion was sent out after the weekly call.
I think the ZLC needs to discuss/vote on the following two points

Mandate if the work needs to be completed
If (1) passes vote, then declare a timeframe for completion. 1.0.0 or can it be pushed after 1.0.0?

From: John Mertic<EMAIL_ADDRESS>Sent: Friday, October 26, 2018 9:03 AM
To: zowe/zlc<EMAIL_ADDRESS>Cc: Ackert, Mark G<EMAIL_ADDRESS>Assign<EMAIL_ADDRESS>Subject: Re: [zowe/zlc] Review @brightside usages for GA (#28)
CAUTION: This email originated from outside of CA. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Saw this was discussed - what are next steps. I think it will be not ideal to have the brightside marks in the Zowe open source project code if that is a mark only being used by CA.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_zowe_zlc_issues_28-23issuecomment-2D433399820&d=DwMCaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=vQmyJ3cryI0pp-72rN6D25sHuAlsustGo1A1CO3U-6A&m=ypnOkhM-AA_pMByez3RIxc3WfHm34nTd7EMbCEyxnAw&s=J_mAIygqZaKFDmJvMaa5anJQu2YpC-ct-g0nj8ecPa0&e=, or mute the threadhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AhrFpmY3X6CYhq3NkGfsZRzd4s-5FLglxvks5uowfrgaJpZM4Wl3-2Da&d=DwMCaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=vQmyJ3cryI0pp-72rN6D25sHuAlsustGo1A1CO3U-6A&m=ypnOkhM-AA_pMByez3RIxc3WfHm34nTd7EMbCEyxnAw&s=MeJ4HAKa9ks2HYdPufedFVvF1by027R2NWVXiFML0Rs&e=.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/zowe/zlc/issues/28#issuecomment-433502044, or mute the thread https://github.com/notifications/unsubscribe-auth/ACxXp5GvUc1R3nUJxrzb3hO_C5EdFlrXks5uo1RogaJpZM4Wl3-a.

Per discussion on the 10-31 ZLC meeting:
Next step: John to engage LF legal and then work with contributoer legal departments to get consensus.  Update at next ZLC target.

@jmertic @zowe/zlc @plavjanik @dkelosky @MikeBauerCA @Joe-Winchester @armstro
Hi All, The CLI squad is looking at beginning conversion of @brightside references to @zowe . Are there any concerns with beginning this conversion activity with a target deployment to the public NPM registry? I don't have the final artifact names, but we would rename @brightside/core to something specific such as @zowe/cli-core to allow sharing the namespace with future Zowe components. Joe Winchester has already reserved the @zowe namespace and I have POC'd the deployment capabilities with zowe-robot.
Thanks

None from my perspective.

@MarkAckert - this sounds like a great idea.  We are currently on a basic plan that is "unlimited public repos" but I did notice that there was a priced plan for private repos.  Is the free plan we're on going to be good enough for our capacity/needs ?

@Joe-Winchester I'm unclear what the requirement for private repos - can you clarify?

I believe the free plan suffices; everything we release will be completely open source. Ditto John's question - did you have a use case in mind for private?

@MarkAckert - no scenarios in mind and I agree that for open source the public plan should suffice.  I just wanted to get another pair of eyes to confirm that so we don't end up in future needing to open someone's wallet without us doing some due diligence.  Tks

Does this mean JIRA is not being considered for this solution going forward? I thought that was the plan...

@jmertic.  JIRA is a tracking issue, similar to products like waffle or zenhub.  I believe the idea is to move towards zenhub which has my vote (for lots of reasons).  The question Mark asked is about npmjs.org which is a way we can host node packages to align with how node deliverables such as the CLI so that we can deliver them to customers.  Currently we deliver CLI either through the broadcomm bintray or else through a zip file - both of which are more foreign to a user than npmjs.org.  We just wanted to verify that using the free plan for npmjs.org was good enough and the answer is Yes.
I hope this helps to clafiry/explain.   Git Issues are work items - we need a tool to replace waffle to track and plan these, zenhub is the obvious replacement.  Jira is in the same market but IMHO a worse solution for Zowe to choose.  Indepently we need a way to host the CLI node package so that customers can consume it - currently we deliver a binary file or else it's in the broadcomm bintray.  We need a more industry open way to do this and npmjs.org/zowe is the right way to do this and we're all happy with staying on the free plan so no future unprepared costs or limitatations are run into

Hey @Joe-Winchester - thanks for the quick response.
I feel we've likely got waaay off track on this GH issue as you are alluding to the core question around npmjs.org. Let me see what the best practices are from other projects and come back with some ideas.
Regarding JIRA - like I said I got the impression from the ZLC meeting last Wednesday that there was serious consideration for this tool. If this changed that's fine - just want to stop setting up JIRA instance for y'all if that's the case.

Closing ... other issues should be opened for Zenhub, Jira or private if needed.


Fix merging and splitting not using the "space" arg

Bug with merging and splitting tokens, used by error rate metrics. Also add option to use different character in the merging and splitting, and use this new functionality to fix the mimic loss recipe.

@pplantinga what is the status of this PR ?


Llama 3 8b Instruct giving garbage response

Prerequisites
Please answer the following questions for yourself before submitting an issue.

[#] I am running the latest code. Development is very rapid so there are no tagged versions as of now.
[#] I carefully followed the README.md.
[#] I searched using keywords relevant to my issue to make sure that I am creating a new issue that is not already open (or closed).
[#] I reviewed the Discussions, and have a new bug or useful enhancement to share.

Expected Behavior
The model should have provided a normal response.
Current Behavior
The model is providing just random garbage values.
Environment and Context
python --version Python 3.11.9
nvidia-smi
Sat Jul  6 12:18:14 2024
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 555.85                 Driver Version: 555.85         CUDA Version: 12.5     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                  Driver-Model | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  Tesla T4                     TCC   |   00000001:00:00.0 Off |                  Off |
| N/A   48C    P0             26W /   70W |   11436MiB /  16384MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI        PID   Type   Process name                              GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|    0   N/A  N/A     10128      C   ...rograms\Python\Python311\python.exe      11416MiB |
+-----------------------------------------------------------------------------------------+
pip show llama-cpp-python Name: llama_cpp_python Version: 0.2.81 Summary: Python bindings for the llama.cpp library Home-page: Author: Author-email: Andrei Betlen<EMAIL_ADDRESS>License: MIT Location: C:\Users\user123\AppData\Local\Programs\Python\Python311\Lib\site-packages Requires: diskcache, jinja2, numpy, typing-extensions Required-by: FlashRank

llama_model_loader: loaded meta data with 22 key-value pairs and 291 tensors from [C:\Users\user123\Downloads\Meta-Llama-3-8B-Instruct.Q5_K_M.gguf](file:///C:/Users/user123/Downloads/Meta-Llama-3-8B-Instruct.Q5_K_M.gguf) (version GGUF V3 (latest))
llama_model_loader: Dumping metadata keys/values. Note: KV overrides do not apply in this output.
llama_model_loader: - kv   0:                       general.architecture str              = llama
llama_model_loader: - kv   1:                               general.name str              = models
llama_model_loader: - kv   2:                          llama.block_count u32              = 32
llama_model_loader: - kv   3:                       llama.context_length u32              = 8192
llama_model_loader: - kv   4:                     llama.embedding_length u32              = 4096
llama_model_loader: - kv   5:                  llama.feed_forward_length u32              = 14336
llama_model_loader: - kv   6:                 llama.attention.head_count u32              = 32
llama_model_loader: - kv   7:              llama.attention.head_count_kv u32              = 8
llama_model_loader: - kv   8:                       llama.rope.freq_base f32              =<PHONE_NUMBER>00
llama_model_loader: - kv   9:     llama.attention.layer_norm_rms_epsilon f32              = 0.000010
llama_model_loader: - kv  10:                          general.file_type u32              = 17
llama_model_loader: - kv  11:                           llama.vocab_size u32              = 128256
llama_model_loader: - kv  12:                 llama.rope.dimension_count u32              = 128
llama_model_loader: - kv  13:                       tokenizer.ggml.model str              = gpt2
llama_model_loader: - kv  14:                         tokenizer.ggml.pre str              = llama-bpe
llama_model_loader: - kv  15:                      tokenizer.ggml.tokens arr[str,128256]  = ["!", """, "#", "$", "%", "&", "'", ...
llama_model_loader: - kv  16:                  tokenizer.ggml.token_type arr[i32,128256]  = [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, ...
llama_model_loader: - kv  17:                      tokenizer.ggml.merges arr[str,280147]  = ["Ġ Ġ", "Ġ ĠĠĠ", "ĠĠ ĠĠ", "...
llama_model_loader: - kv  18:                tokenizer.ggml.bos_token_id u32              = 128000
llama_model_loader: - kv  19:                tokenizer.ggml.eos_token_id u32              = 128001
llama_model_loader: - kv  20:                    tokenizer.chat_template str              = {% set loop_messages = messages %}{% ...
llama_model_loader: - kv  21:               general.quantization_version u32              = 2
llama_model_loader: - type  f32:   65 tensors
llama_model_loader: - type q5_K:  193 tensors
llama_model_loader: - type q6_K:   33 tensors
llm_load_vocab: special tokens cache size = 256
llm_load_vocab: token to piece cache size = 0.8000 MB
llm_load_print_meta: format           = GGUF V3 (latest)
llm_load_print_meta: arch             = llama
llm_load_print_meta: vocab type       = BPE
llm_load_print_meta: n_vocab          = 128256
llm_load_print_meta: n_merges         = 280147
llm_load_print_meta: n_ctx_train      = 8192
llm_load_print_meta: n_embd           = 4096
llm_load_print_meta: n_head           = 32
llm_load_print_meta: n_head_kv        = 8
llm_load_print_meta: n_layer          = 32
llm_load_print_meta: n_rot            = 128
llm_load_print_meta: n_swa            = 0
llm_load_print_meta: n_embd_head_k    = 128
llm_load_print_meta: n_embd_head_v    = 128
llm_load_print_meta: n_gqa            = 4
llm_load_print_meta: n_embd_k_gqa     = 1024
llm_load_print_meta: n_embd_v_gqa     = 1024
llm_load_print_meta: f_norm_eps       = 0.0e+00
llm_load_print_meta: f_norm_rms_eps   = 1.0e-05
llm_load_print_meta: f_clamp_kqv      = 0.0e+00
llm_load_print_meta: f_max_alibi_bias = 0.0e+00
llm_load_print_meta: f_logit_scale    = 0.0e+00
llm_load_print_meta: n_ff             = 14336
llm_load_print_meta: n_expert         = 0
llm_load_print_meta: n_expert_used    = 0
llm_load_print_meta: causal attn      = 1
llm_load_print_meta: pooling type     = 0
llm_load_print_meta: rope type        = 0
llm_load_print_meta: rope scaling     = linear
llm_load_print_meta: freq_base_train  = 500000.0
llm_load_print_meta: freq_scale_train = 1
llm_load_print_meta: n_ctx_orig_yarn  = 8192
llm_load_print_meta: rope_finetuned   = unknown
llm_load_print_meta: ssm_d_conv       = 0
llm_load_print_meta: ssm_d_inner      = 0
llm_load_print_meta: ssm_d_state      = 0
llm_load_print_meta: ssm_dt_rank      = 0
llm_load_print_meta: model type       = 8B
llm_load_print_meta: model ftype      = Q5_K - Medium
llm_load_print_meta: model params     = 8.03 B
llm_load_print_meta: model size       = 5.33 GiB (5.70 BPW)
llm_load_print_meta: general.name     = models
llm_load_print_meta: BOS token        = 128000 '<|begin_of_text|>'
llm_load_print_meta: EOS token        = 128001 '<|end_of_text|>'
llm_load_print_meta: LF token         = 128 'Ä'
llm_load_print_meta: EOT token        = 128009 '<|eot_id|>'
llm_load_print_meta: max token length = 256
llm_load_tensors: ggml ctx size =    0.27 MiB
llm_load_tensors: offloading 32 repeating layers to GPU
llm_load_tensors: offloading non-repeating layers to GPU
llm_load_tensors: offloaded 33/33 layers to GPU
llm_load_tensors:        CPU buffer size =   344.44 MiB
llm_load_tensors:      CUDA0 buffer size =  5115.49 MiB
.........................................................................................
llama_new_context_with_model: n_batch is less than GGML_KQ_MASK_PAD - increasing to 32
llama_new_context_with_model: n_ctx      = 2048
llama_new_context_with_model: n_batch    = 32
llama_new_context_with_model: n_ubatch   = 32
llama_new_context_with_model: flash_attn = 0
llama_new_context_with_model: freq_base  = 10000.0
llama_new_context_with_model: freq_scale = 1
llama_kv_cache_init:      CUDA0 KV buffer size =   256.00 MiB
llama_new_context_with_model: KV self size  =  256.00 MiB, K (f16):  128.00 MiB, V (f16):  128.00 MiB
llama_new_context_with_model:  CUDA_Host  output buffer size =     0.49 MiB
llama_new_context_with_model:      CUDA0 compute buffer size =    16.16 MiB
llama_new_context_with_model:  CUDA_Host compute buffer size =     0.75 MiB
llama_new_context_with_model: graph nodes  = 1030
llama_new_context_with_model: graph splits = 2
AVX = 1 | AVX_VNNI = 0 | AVX2 = 1 | AVX512 = 0 | AVX512_VBMI = 0 | AVX512_VNNI = 0 | AVX512_BF16 = 0 | FMA = 1 | NEON = 0 | SVE = 0 | ARM_FMA = 0 | F16C = 1 | FP16_VA = 0 | WASM_SIMD = 0 | BLAS = 1 | SSE3 = 1 | SSSE3 = 1 | VSX = 0 | MATMUL_INT8 = 0 | LLAMAFILE = 0 |
Model metadata: {'general.name': 'models', 'general.architecture': 'llama', 'llama.block_count': '32', 'llama.context_length': '8192', 'tokenizer.ggml.eos_token_id': '128001', 'general.file_type': '17', 'llama.attention.head_count_kv': '8', 'llama.embedding_length': '4096', 'llama.feed_forward_length': '14336', 'llama.attention.head_count': '32', 'llama.rope.freq_base': '500000.000000', 'llama.attention.layer_norm_rms_epsilon': '0.000010', 'llama.vocab_size': '128256', 'llama.rope.dimension_count': '128', 'tokenizer.ggml.model': 'gpt2', 'tokenizer.ggml.pre': 'llama-bpe', 'general.quantization_version': '2', 'tokenizer.ggml.bos_token_id': '128000', 'tokenizer.chat_template': "{% set loop_messages = messages %}{% for message in loop_messages %}{% set content = '<|start_header_id|>' + message['role'] + '<|end_header_id|>\n\n'+ message['content'] | trim + '<|eot_id|>' %}{% if loop.index0 == 0 %}{% set content = bos_token + content %}{% endif %}{{ content }}{% endfor %}{% if add_generation_prompt %}{{ '<|start_header_id|>assistant<|end_header_id|>\n\n' }}{% endif %}"}
Available chat formats from metadata: chat_template.default
Guessed chat format: llama-3

Code :-
from langchain_core.callbacks import CallbackManager, StreamingStdOutCallbackHandler
from langchain_community.llms import LlamaCpp
callback_manager = CallbackManager([StreamingStdOutCallbackHandler()])
llm = LlamaCpp(
model_path="C:\Users\user123\Downloads\Meta-Llama-3-8B-Instruct.Q5_K_M.gguf",
callback_manager = callback_manager,
n_ctx=2048,
max_tokens = 4096,
n_gpu_layers=-1,
verbose=True,
top_p = 0.95,
min_p = 0.05,
frequency_penalty = 0.0,
presence_penalty = 0.0,
repeat_penalty = 1.1,
top_k = 40,
f16_kv=True,
stop = ["<end>"],
temperature = 0,
seed = 2000,
)
prompt_template = """
<|begin_of_text|><|start_header_id|>system<|end_header_id|>
Use the following pieces of information to answer the user's question.
If you don't know the answer, just say that you don't know, don't try to make up an answer.
Context: {context}
Question: {question}
Answer the question and provide additional helpful information,
based on the pieces of information, if applicable. Be succinct.
End the response with  tag which is must.
Responses should be properly formatted and structured so that it can be easily read.
Helpful and the most accurate response from the context and relevant to question :- <|eot_id|>
<|start_header_id|>assistant<|end_header_id|>
"""
prompt = PromptTemplate(
template=prompt_template, input_variables=["context", "question"]
)

> Entering new StuffDocumentsChain chain...
> Entering new LLMChain chain...
Prompt after formatting:

<|begin_of_text|><|start_header_id|>system<|end_header_id|>
Use the following pieces of information to answer the user's question.
If you don't know the answer, just say that you don't know, don't try to make up an answer.
Context: Instructions for Use Attachment B  Reference Database 2 for Healthy Eyes Study–CIRRUS 6000
CIRRUS HD-OCT B.8 ONH and RNFL Images
2660021178037 Rev C 465 / 488B.7.2.1 Ganglion Cell Data
Type
Variablen Mean (SD) 95% CI Min Max
Ganglion Cell Thickness
Average Thickness (µm) 826 80.46 (6.36) [80.02, 80.89] 61.00 100.00
Temporal Superior (µm) 826 79.60 (6.25) [79.17, 80.03] 60.00 100.00
Superior (µm) 826 80.98 (6.73) [80.52, 81.44] 59.00 102.00
Nasal Superior (µm) 826 82.16 (7.12) [81.68, 82.65] 58.00 100.00
Nasal Inferior (µm) 826 80.49 (7.13) [80.00, 80.97] 59.00 99.00
Inferior (µm) 826 78.84 (6.83) [78.37, 79.30] 58.00 100.00
Temporal Inferior (µm) 826 80.71 (6.36) [80.28, 81.15] 61.00 103.00
Table 93: Summary of variables, Macular Cube 200x200
B.8ONH and RNFL Images
NOTE! These parameters are adjusted for age and optic disc
area.
Measurement Parameters Analyses
RNFL Thickness • RNFL Summary Parameters:
–Average RNFL Thickness
–Temporal Average RNFL
Thickness
–Superior Average RNFL
Thickness
–Nasal Average RNFL
Thickness
–Inferior Average RNFL
Thickness
–Inter-eye symmetry (RNFL)
–Clock hour parameters
–TSNIT Profiles
–Neuro-Retinal Rim
–RNFL Thickness
–RNFL Deviation Map• ONH/RNFL OU
• Panomap
• Single Eye Summary
• Wellness Report
ONH Features • Rim Area (mm2)
• Average Cup-to-Disc Ratio
• Vertical Cup-to-Disc Ratio
• Cup Volume (mm3)• ONH/RNFL OU
• Panomap
• Single Eye Summary
Table 94: RNFL thickness and ONH Parameters and Analyses with RDB Data
Also see
2Analyze ONH/RNFL OU [ } 276]
Instructions for Use 8 Analyzing Exam Data and Creating Reports
CIRRUS HD-OCT 8.2 Posterior Segment Scan Analysis
2660021178037 Rev C 279 / 488# Symbol Explanation
Rotation Tool
Changes the angle of the ONH spoke.
<IP_ADDRESS>.3 Analyzing ONH and RNFL
The ONH and RNFL OU Analysis  uses two kinds of thickness
measurements:
•RNFL grid
When you move the RNFL grid, the thickness maps, deviation
maps, and ONH calculations update automatically.
•Super-pixels
A total of 50 x 50 (2500) super-pixels are analyzed (optic disc
excluded).
RNFL Thickness Maps  report thickness by showing blue or green
for thinner areas and yellow or red for thicker areas (the optic disc
appears solid blue).
Deviation Maps  compare the reference range for healthy eyes for
the patient's age and show yellow and red areas that are thinner
than 95% and 99% of the (age and optic disc size-adjusted)
population, respectively.
Interpretation Considerations
For some patients, deviation maps can show decrease due to
reasons other than pathology. such as:
•The patient has strongly myopic or hyperopic eyes
•The patient has split-bundle anatomy
•The patient has a tilted RNFL bundle pattern
If the patient's temporal RNFL that is very thin or absent, the maps
might show thickened RNFL.
CIRRUS™ HD-OCT  compares the RNFL thickness and symmetry of
the scan(s) with the reference range for healthy eyes for the
patient's age.
Attachment B  Reference Database 2 for Healthy Eyes Study–CIRRUS 6000 Instructions for Use
CIRRUS HD-OCT B.8 ONH and RNFL Images
466 /<PHONE_NUMBER>178037 Rev CB.8.1 ONH Parameters
The data originally collected for the database was analyzed to
create the reference ranges for the following ONH parameters:
•Rim Area (mm2)
•Average Cup to Disc Ratio (square root of cup area over disc
area)
•Vertical Cup to Disc Ratio (cup height over disc height)
•Cup Volume (mm3)
B.8.2 RNFL Parameters
This study determined the reference range for healthy eyes for the
following the retinal nerve fiber layer (RNFL) parameters in healthy
subjects ages 18 to 88:
•Average RNFL Thickness
•Temporal Average RNFL Thickness
•Superior Average RNFL Thickness
•Nasal Average RNFL Thickness
•Inferior Average RNFL Thickness
•Inter-eye symmetry (RNFL)
•Clock hour parameters
•TSNIT Profiles
•Neuro-Retinal Rim
•RNFL Thickness
•RNFL Deviation Map
B.8.3 ONH and RNFL Data
Type
Variablen Mean (SD) 95% CI Min Max
ONH
Rim Area (mm2) 854 1.30 (0.23) [1.28, 1.31] 0.74 2.21
Average Cup/Disc Ratio 854 0.46 (0.17) [0.45, 0.47] 0.06 0.74
Vertical C/D Ratio 854 0.44 (0.16) [0.43, 0.45] 0.05 0.75
Cup Volume (mm3) 854 0.13 (0.12) [0.12, 0.14] 0.00 0.70
RNFL Thickness
Average RNFL Thickness (µm) 854 93.19 (9.28) [92.57, 93.81] 69.00 126.00
Temporal (µm) 854 64.04 (11.53) [63.26, 64.81] 40.00 120.00
Superior (µm) 854 115.05 (15.92) [113.98, 116.12] 72.00 162.00
Nasal (µm) 854 72.35 (11.54) [71.58, 73.13] 41.00 115.00
Inferior (µm) 854 121.37 (16.08) [120.29, 122.45] 72.00 188.00
Clock hour 1 (µm) 854 105.56 (23.11) [104.01, 107.11] 51.00 185.00
Clock hour 2 (µm) 854 88.60 (18.10) [87.39, 89.82] 43.00 160.00
Clock hour 3 (µm) 854 60.73 (10.53) [60.02, 61.44] 38.00 103.00
Clock hour 4 (µm) 854 67.78 (13.79) [66.85, 68.70] 37.00 129.00
Question: What is RNFL Clock hours in ONH and RNFL OU Analysis?
Answer the question and provide additional helpful information,
based on the pieces of information, if applicable. Be succinct.
End the response with  tag which is must.
Responses should be properly formatted and structured so that it can be easily read.
Helpful and the most accurate response from the context and relevant to question :- <|eot_id|>
<|start_header_id|>assistant<|end_header_id|>

Llama.generate: prefix-match hit
•
2
  }
}  B
}  }  }  }  }  }
}  F
  }  }  }  }  }  }  }  }  }  }  }  [C
}
}  } •
  }
  }  } 2.  }  }  }  }  }  }  }  }  }  }  }  }  }   }  }  }  }  }  }  }  }  }  }  }  }  }  }  } } •
    }        }   }  }  }
}  }  } }
}  }   } .  }  .
 •  } &  }  } .  } •
•
•
}  } •
  } } •
  }  } •
llama_print_timings:        load time =     124.22 ms
llama_print_timings:      sample time =     206.91 ms /   224 runs   (    0.92 ms per token,  1082.61 tokens per second)
llama_print_timings: prompt eval time =   19358.81 ms /  1776 tokens (   10.90 ms per token,    91.74 tokens per second)
llama_print_timings:        eval time =    7789.25 ms /   224 runs   (   34.77 ms per token,    28.76 tokens per second)
llama_print_timings:       total time =   27901.02 ms /  2000 tokens
> Finished chain.
> Finished chain.
{'query': 'What is RNFL Clock hours in ONH and RNFL OU Analysis?', 'result': '•\n2\n\xa0 }\n\n\xa0 }\xa0 B\n }\xa0 }\xa0 }\xa0 }\xa0 }\xa0 }\n\n\n\n\n }\xa0 F\n\xa0 }\xa0 }\xa0 }\xa0 }\xa0 }\xa0 }\xa0 }\xa0 }\xa0 }\xa0 }\xa0 }\xa0 [C\n\n\xa0}\n\n\xa0 }\xa0 }\xa0•\n\xa0 }\n\xa0 }\xa0 }\xa02.\xa0 }\xa0 }\xa0 }\xa0 }\xa0 }\xa0 }\xa0 }\xa0 }\xa0 }\xa0 }\xa0 }\xa0 }\xa0 }\xa0\xa0 }\xa0 }\xa0 }\xa0 }\xa0 }\xa0 }\xa0 }\xa0 }\xa0 }\xa0 }\xa0 }\xa0 }\xa0 }\xa0 }\xa0 }\xa0}\xa0•\n\xa0\xa0\xa0 }\xa0\xa0\xa0\xa0\xa0\xa0\xa0 }\xa0\xa0 }\xa0 }\xa0 }\n\n\xa0 }\xa0 }\xa0 }\xa0}\n\n\xa0 }\xa0 }\xa0\xa0 }\xa0.\xa0 }\xa0\xa0.\n\xa0•\xa0 }\xa0&\xa0 }\xa0 }\xa0.\xa0 }\xa0•\n•\n•\n }\xa0 }\xa0•\n\xa0 }\xa0}\xa0•\n\xa0 }\xa0 }\xa0•\n\n', 'source_documents': [Document(page_content='Instructions for Use Attachment B  Reference Database 2 for Healthy Eyes Study–CIRRUS 6000\nCIRRUS HD-OCT B.8 ONH and RNFL Images\n2660021178037 Rev C 465 / 488B.7.2.1 Ganglion Cell Data\nType\nVariablen Mean (SD) 95% CI Min Max\nGanglion Cell Thickness\nAverage Thickness (µm) 826 80.46 (6.36) [80.02, 80.89] 61.00 100.00\nTemporal Superior (µm) 826 79.60 (6.25) [79.17, 80.03] 60.00 100.00\nSuperior (µm) 826 80.98 (6.73) [80.52, 81.44] 59.00 102.00\nNasal Superior (µm) 826 82.16 (7.12) [81.68, 82.65] 58.00 100.00\nNasal Inferior (µm) 826 80.49 (7.13) [80.00, 80.97] 59.00 99.00\nInferior (µm) 826 78.84 (6.83) [78.37, 79.30] 58.00 100.00\nTemporal Inferior (µm) 826 80.71 (6.36) [80.28, 81.15] 61.00 103.00\nTable\xa093: Summary of variables, Macular Cube 200x200\nB.8ONH and RNFL Images\nNOTE!\xa0These parameters are adjusted for age and optic disc\narea.\nMeasurement Parameters Analyses\nRNFL Thickness • RNFL Summary Parameters:\n–Average RNFL Thickness\n–Temporal Average RNFL\nThickness\n–Superior Average RNFL\nThickness\n–Nasal Average RNFL\nThickness\n–Inferior Average RNFL\nThickness\n–Inter-eye symmetry (RNFL)\n–Clock hour parameters\n–TSNIT Profiles\n–Neuro-Retinal Rim\n–RNFL Thickness\n–RNFL Deviation Map• ONH/RNFL OU\n• Panomap\n• Single Eye Summary\n• Wellness Report\nONH Features • Rim Area (mm2)\n• Average Cup-to-Disc Ratio\n• Vertical Cup-to-Disc Ratio\n• Cup Volume (mm3)• ONH/RNFL OU\n• Panomap\n• Single Eye Summary\nTable\xa094: RNFL thickness and ONH Parameters and Analyses with RDB Data\nAlso see\n2Analyze ONH/RNFL OU [ }\xa0276]', metadata={'source': 'C:\Users\user123\Downloads\content\2660021178037_c_cirrus_6000_11.7_ifu_enus.pdf', 'page': 464, '_id': '077141c62da74d258f7a468285030b8f', '_collection_name': 'document_embeddings', 'relevance_score': 0.9270478}), Document(page_content="Instructions for Use 8 Analyzing Exam Data and Creating Reports\nCIRRUS HD-OCT 8.2 Posterior Segment Scan Analysis\n2660021178037 Rev C 279 / 488# Symbol Explanation\nRotation Tool\n Changes the angle of the ONH spoke.\n<IP_ADDRESS>.3 Analyzing ONH and RNFL\nThe ONH and RNFL OU Analysis  uses two kinds of thickness\nmeasurements:\n•RNFL grid\nWhen you move the RNFL grid, the thickness maps, deviation\nmaps, and ONH calculations update automatically.\n•Super-pixels\nA total of 50 x 50 (2500) super-pixels are analyzed (optic disc\nexcluded).\nRNFL Thickness Maps  report thickness by showing blue or green\nfor thinner areas and yellow or red for thicker areas (the optic disc\nappears solid blue).\nDeviation Maps  compare the reference range for healthy eyes for\nthe patient's age and show yellow and red areas that are thinner\nthan 95% and 99% of the (age and optic disc size-adjusted)\npopulation, respectively.\nInterpretation Considerations\nFor some patients, deviation maps can show decrease due to\nreasons other than pathology. such as:\n•The patient has strongly myopic or hyperopic eyes\n•The patient has split-bundle anatomy\n•The patient has a tilted RNFL bundle pattern\nIf the patient's temporal RNFL that is very thin or absent, the maps\nmight show thickened RNFL.\nCIRRUS™ HD-OCT  compares the RNFL thickness and symmetry of\nthe scan(s) with the reference range for healthy eyes for the\npatient's age.", metadata={'source': 'C:\Users\user123\Downloads\content\2660021178037_c_cirrus_6000_11.7_ifu_enus.pdf', 'page': 278, '_id': '253d8f9d11694dec87f1b6374ee4baa8', '_collection_name': 'document_embeddings', 'relevance_score': 0.82976836}), Document(page_content='Attachment B  Reference Database 2 for Healthy Eyes Study–CIRRUS 6000 Instructions for Use\nCIRRUS HD-OCT B.8 ONH and RNFL Images\n466 /<PHONE_NUMBER>178037 Rev CB.8.1 ONH Parameters\nThe data originally collected for the database was analyzed to\ncreate the reference ranges for the following ONH parameters:\n•Rim Area (mm2)\n•Average Cup to Disc Ratio (square root of cup area over disc\narea)\n•Vertical Cup to Disc Ratio (cup height over disc height)\n•Cup Volume (mm3)\nB.8.2 RNFL Parameters\nThis study determined the reference range for healthy eyes for the\nfollowing the retinal nerve fiber layer (RNFL) parameters in healthy\nsubjects ages 18 to 88:\n•Average RNFL Thickness\n•Temporal Average RNFL Thickness\n•Superior Average RNFL Thickness\n•Nasal Average RNFL Thickness\n•Inferior Average RNFL Thickness\n•Inter-eye symmetry (RNFL)\n•Clock hour parameters\n•TSNIT Profiles\n•Neuro-Retinal Rim\n•RNFL Thickness\n•RNFL Deviation Map\nB.8.3 ONH and RNFL Data\nType\nVariablen Mean (SD) 95% CI Min Max\nONH\nRim Area (mm2) 854 1.30 (0.23) [1.28, 1.31] 0.74 2.21\nAverage Cup/Disc Ratio 854 0.46 (0.17) [0.45, 0.47] 0.06 0.74\nVertical C/D Ratio 854 0.44 (0.16) [0.43, 0.45] 0.05 0.75\nCup Volume (mm3) 854 0.13 (0.12) [0.12, 0.14] 0.00 0.70\nRNFL Thickness\nAverage RNFL Thickness (µm) 854 93.19 (9.28) [92.57, 93.81] 69.00 126.00\nTemporal (µm) 854 64.04 (11.53) [63.26, 64.81] 40.00 120.00\nSuperior (µm) 854 115.05 (15.92) [113.98, 116.12] 72.00 162.00\nNasal (µm) 854 72.35 (11.54) [71.58, 73.13] 41.00 115.00\nInferior (µm) 854 121.37 (16.08) [120.29, 122.45] 72.00 188.00\nClock hour 1 (µm) 854 105.56 (23.11) [104.01, 107.11] 51.00 185.00\nClock hour 2 (µm) 854 88.60 (18.10) [87.39, 89.82] 43.00 160.00\nClock hour 3 (µm) 854 60.73 (10.53) [60.02, 61.44] 38.00 103.00\nClock hour 4 (µm) 854 67.78 (13.79) [66.85, 68.70] 37.00 129.00', metadata={'source': 'C:\Users\user123\Downloads\content\xyz.pdf', 'page': 465, '_id': '0c53f682055f48a7a373a0f5543ba7df', '_collection_name': 'document_embeddings', 'relevance_score': 0.75868905})]}
Quantized model :- https://huggingface.co/QuantFactory/Meta-Llama-3-8B-Instruct-GGUF/tree/main
https://huggingface.co/QuantFactory/Meta-Llama-3-8B-Instruct-GGUF/blob/main/Meta-Llama-3-8B-Instruct.Q5_K_M.gguf

I obtained following using your values. Try removing <|begin_of_text|> as it should be handled internally by llama.
Additionally, f16_kv=True appears to be deprecated since version 0.2.24

RNFL Clock Hours in ONH and RNFL OU Analysis:
In the CIRRUS HD-OCT system, RNFL Clock hours refer to a specific analysis of the retinal nerve fiber layer (RNFL) thickness measurements. This analysis is part of the ONH and RNFL OU Analysis.
The RNFL Clock hours analysis provides information on the thickness of the RNFL at different clock hour positions around the optic disc. The clock hour positions are:

Clock hour 1: Superior nasal
Clock hour 2: Superior temporal
Clock hour 3: Inferior temporal
Clock hour 4: Inferior nasal

This analysis helps to assess the symmetry and thickness of the RNFL, which can be useful in diagnosing and monitoring various retinal diseases.
Additional Information:
The RNFL Clock hours analysis is based on a reference database of healthy eyes, which provides a range of normal values for each clock hour position.
The system compares the patient's measurements to these reference values to provide an assessment of their RNFL thickness and symmetry.
Tag: #CIRRUSHD-OCT

Something interesting happened. The model I used to generate the response in my previous post was Meta-Llama-3-8B-Instruct-old-GGUF (Q4_K_M), which has an issue with BPE tokens and displays the following warning:
llm_load_vocab: missing pre-tokenizer type, using: 'default'
llm_load_vocab:
llm_load_vocab: ************************************
llm_load_vocab: GENERATION QUALITY WILL BE DEGRADED!
llm_load_vocab: CONSIDER REGENERATING THE MODEL
llm_load_vocab: ************************************

I replaced that model with the updated version, Meta-Llama-3-8B-Instruct-GGUF (Q4_K_M), which has the BPE tokenizers fixed. And here's the response generated with the exact same code:
RNFL Clock Hours are a type of measurement parameter in ONH and RNFL OU Analysis, which refers to the thickness measurements taken at specific clock hour positions around the optic disc.

Additional helpful information:
* The CIRRUS HD-OCT system uses 12 clock hours (0-11) to measure RNFL thickness.
* Each clock hour position corresponds to a specific sector of the optic disc.
* The RNFL Clock Hours measurement is used to assess the symmetry and thickness of the retinal nerve fiber layer.

Tag: #ONHandRNFLAnalysis

I'm not exactly an ophthalmologist, but it seems like the response quality has degraded, right?

Hi @i486, While i was checking this issue, i had build llama.cpp server with the exact same model and didn't notice any of these issue's there.

I'm not exactly an ophthalmologist, but it seems like the response quality has degraded, right?

Well looking at the responses the first one is more accurate than second one. In the second one the additional details should be inside the main answer.

Hi @i486 did tried again the below was the prompt.

<|start_header_id|>system<|end_header_id|>

Use the following pieces of information to answer the user's question.
If you don't know the answer, just say that you don't know, don't try to make up an answer.
Context: Instructions for Use 8 Analyzing Exam Data and Creating Reports
CIRRUS HD-OCT 8.2 Posterior Segment Scan Analysis
2660021178037 Rev C 279 / 488# Symbol Explanation
Rotation Tool
Changes the angle of the ONH spoke.
<IP_ADDRESS>.3 Analyzing ONH and RNFL
The ONH and RNFL OU Analysis  uses two kinds of thickness
measurements:
•RNFL grid
When you move the RNFL grid, the thickness maps, deviation
maps, and ONH calculations update automatically.
•Super-pixels
A total of 50 x 50 (2500) super-pixels are analyzed (optic disc
excluded).
RNFL Thickness Maps  report thickness by showing blue or green
for thinner areas and yellow or red for thicker areas (the optic disc
appears solid blue).
Deviation Maps  compare the reference range for healthy eyes for
the patient's age and show yellow and red areas that are thinner
than 95% and 99% of the (age and optic disc size-adjusted)
population, respectively.
Interpretation Considerations
For some patients, deviation maps can show decrease due to
reasons other than pathology. such as:
•The patient has strongly myopic or hyperopic eyes
•The patient has split-bundle anatomy
•The patient has a tilted RNFL bundle pattern
If the patient's temporal RNFL that is very thin or absent, the maps
might show thickened RNFL.
CIRRUS™ HD-OCT  compares the RNFL thickness and symmetry of
the scan(s) with the reference range for healthy eyes for the
patient's age.
Instructions for Use 8 Analyzing Exam Data and Creating Reports
CIRRUS HD-OCT 8.2 Posterior Segment Scan Analysis
2660021178037 Rev C 275 / 488Shape Indication
Quadrants (Superior, Nasal, Temporal, Inferior)
Clock Hours
Table 63: Shape Key for the RNFL reference database for healthy eyes
Analysis Interpretation
Thickness
Map
Two examples of thickness maps; interpreted as:
•blue and green = thinner areas
•yellow and red = thicker areas
•solid blue circle = optic disc
Deviation
from
Reference
Map
Two examples that show:
Red and yellow areas shows where this scan has areas that are thinner than the reference
range for healthy eyes.
Thinner regions do not necessary indicate pathological loss of RNFL. Red and yellow areas
can also appear for:
•Strongly myopic or hyperopic eyes (which may have a different distribution of measured
RNFL thickness values)
•Split-bundle anatomy
•A very tilted RNFL bundle
Quadrant
Average
(more detailed
comparison)
Right Eye
•Superior quadrant average is 86 µm  and Borderline Thin
•Nasal quadrant average is 45 µm  and Borderline Thin
•Inferior quadrant average is 81 µm  and Thin
•Temporal quadrant average is 79 µm  and Healthy
Left Eye
•Superior quadrant average is 77 µm  and Thin
•Temporal quadrant average is 70 µm  and Healthy
•Inferior quadrant average is 50 µm  and Thin
•Nasal quadrant average is 45 µm  and Borderline Thin
Clock Hour
Average (most
detailed
comparison)Shows the measurement for each clock hour and indicates whether the measurement is
within 90% of reference limits of healthy eyes (green), within 5% of reference limits of
healthy eyes (yellow) or within 1% of reference limits of healthy eyes (red).
8 Analyzing Exam Data and Creating Reports Instructions for Use
CIRRUS HD-OCT 8.2 Posterior Segment Scan Analysis
278 /<PHONE_NUMBER>178037 Rev C# Symbol Explanation
3 Reference Range
Comparison
Displays measurements with color-coded comparison to the reference range
for the patient's age.
4 Quadrant Averages
Shows the RNFL thickness for each eye in four quadrants (Superior, Nasal,
Temporal, Inferior)
RNFL Thickness
Chart
Displays thickness profiles.
•TSNIT
5 RNFL Clock Hours
Shows the measurement for each clock hour and indicates whether the
measurement is within 90% of the reference limit range of healthy eyes
(green), within 5% of the reference limit range of healthy eyes (yellow) or
within 1% of the reference limit range of healthy eyes (red).
6
RNFL thickness map.
7
Vertical B-scan: slice through cube top to bottom relative to LSO fundus
image.
8
Horizontal B-Scan: slice through cube side to side relative to LSO fundus
image.
RNFL circle scan extracted along 3.46 mm diameter Calculation Circle
9 Angle Indicator Shows the angle of the ONH spoke.
Question: What is RNFL Clock hours in ONH and RNFL OU Analysis?
Answer the question and provide additional helpful information,
based on the pieces of information, if applicable. Be succinct.
End the response with tag which is must.
Responses should be properly formatted and structured so that it can be easily read.
Helpful and the most accurate response from the context and relevant to question :- <|eot_id|>
<|start_header_id|>assistant<|end_header_id|>
Response :-
8 "you\n8 Post Post Post 8 C- up a 8 HD-9 8 HD 8 HD 8 HD 8 HD 8 HD 8 HD 8 HD 8 HD 8 HD 8 HD 8 HD 0.0 symbol post\nC\n Symbol\n C\n C 8 HDT Post Post Post Post S Post Post Post Post Post the Post Post: Post Post-Post Post and Post Post ON 8 8 Post Post Post Post Post\n C\nC\n Post Post Post on the Post ON\n\n C/ Post On "C\n C\n C\n C\n C\n Rot \n C\n The post ON the ON the post the ON the ON the post the post on the ON post post the ON ON HD Post ON post post post ON post post post the post post the post to the post ON the post the post ON the post the post the ON up the post 8 HD Post ON the post the ON the On the ON the ON the post on the ON S ON C\nC\n\n Symbol or the ON C\nC ON Post On Post Post Post Post On Post On Post ON C on the ON C On the ON C On the ON C ON C ON C On the ON Post
Now The params
llm = LlamaCpp(
model_path="/kaggle/input/llama3-8b-q4/Meta-Llama-3-8B-Instruct-Q4_K_M.gguf",
n_ctx=4096,
n_gpu_layers=-1,
verbose=True,
stop = [""],
temperature = 0,
seed = 2000,
)
Here there are two things to notice :-

When i lower the amount of token in the input i get normal response. But when increased the vice-versa happens.
The same was checked with llama.cpp with default params and just the -c 4096 and it was working absolutely great.

Hi, @gformcreation
I just realized (sry for not catching it earlier) that your codes doesn't have user prompt, which is likely causing the gibberish responses. Give this one a try and see if you get a normal response.
from llama_cpp import Llama

llm = Llama(
    # model_path=r"G:\Models\gemma-2-9b-it-IQ3_XXS\gemma-2-9b-it-IQ3_XXS.gguf",
    # model_path=r"G:\Models\gemma-2-9b-it-Q3_K_M\gemma-2-9b-it-Q3_K_M.gguf",
    # model_path=r"G:\Models\gemma-2-9b-it-IQ4_XS\gemma-2-9b-it-IQ4_XS.gguf",
    model_path=r"G:\Models\Meta-Llama-3-8B-Instruct-Q4_K_M\Meta-Llama-3-8B-Instruct-Q4_K_M.gguf",
    # model_path=r"G:\Models\",
    # model_path=r"G:\Models\",
    n_ctx=4096,
    n_threads=6,
    n_gpu_layers=-1,
    # use_mmap=False,
    # use_mlock=False,
    # offload_kqv=True,
    # offload_kqv=False,
    # flash_attn=True,
    # flash_attn=False,
    # n_batch=32,
    # rope_freq_base=10000,
    verbose=True,
    )

prompt = """
<|start_header_id|>system<|end_header_id|>

Use the following pieces of information to answer the user's question.
If you don't know the answer, just say that you don't know, don't try to make up an answer.

Context: Instructions for Use Attachment B Reference Database 2 for Healthy Eyes Study–CIRRUS 6000
CIRRUS HD-OCT B.8 ONH and RNFL Images
2660021178037 Rev C 465 / 488B.7.2.1 Ganglion Cell Data
Type
Variablen Mean (SD) 95% CI Min Max
Ganglion Cell Thickness
Average Thickness (µm) 826 80.46 (6.36) [80.02, 80.89] 61.00 100.00
Temporal Superior (µm) 826 79.60 (6.25) [79.17, 80.03] 60.00 100.00
Superior (µm) 826 80.98 (6.73) [80.52, 81.44] 59.00 102.00
Nasal Superior (µm) 826 82.16 (7.12) [81.68, 82.65] 58.00 100.00
Nasal Inferior (µm) 826 80.49 (7.13) [80.00, 80.97] 59.00 99.00
Inferior (µm) 826 78.84 (6.83) [78.37, 79.30] 58.00 100.00
Temporal Inferior (µm) 826 80.71 (6.36) [80.28, 81.15] 61.00 103.00
Table 93: Summary of variables, Macular Cube 200x200
B.8ONH and RNFL Images
NOTE! These parameters are adjusted for age and optic disc
area.
Measurement Parameters Analyses
RNFL Thickness • RNFL Summary Parameters:
–Average RNFL Thickness
–Temporal Average RNFL
Thickness
–Superior Average RNFL
Thickness
–Nasal Average RNFL
Thickness
–Inferior Average RNFL
Thickness
–Inter-eye symmetry (RNFL)
–Clock hour parameters
–TSNIT Profiles
–Neuro-Retinal Rim
–RNFL Thickness
–RNFL Deviation Map• ONH/RNFL OU
• Panomap
• Single Eye Summary
• Wellness Report
ONH Features • Rim Area (mm2)
• Average Cup-to-Disc Ratio
• Vertical Cup-to-Disc Ratio
• Cup Volume (mm3)• ONH/RNFL OU
• Panomap
• Single Eye Summary
Table 94: RNFL thickness and ONH Parameters and Analyses with RDB Data
Also see
2Analyze ONH/RNFL OU [ } 276]

Instructions for Use 8 Analyzing Exam Data and Creating Reports
CIRRUS HD-OCT 8.2 Posterior Segment Scan Analysis
2660021178037 Rev C 279 / 488# Symbol Explanation
Rotation Tool
Changes the angle of the ONH spoke.
<IP_ADDRESS>.3 Analyzing ONH and RNFL
The ONH and RNFL OU Analysis uses two kinds of thickness
measurements:
•RNFL grid
When you move the RNFL grid, the thickness maps, deviation
maps, and ONH calculations update automatically.
•Super-pixels
A total of 50 x 50 (2500) super-pixels are analyzed (optic disc
excluded).
RNFL Thickness Maps report thickness by showing blue or green
for thinner areas and yellow or red for thicker areas (the optic disc
appears solid blue).
Deviation Maps compare the reference range for healthy eyes for
the patient's age and show yellow and red areas that are thinner
than 95% and 99% of the (age and optic disc size-adjusted)
population, respectively.
Interpretation Considerations
For some patients, deviation maps can show decrease due to
reasons other than pathology. such as:
•The patient has strongly myopic or hyperopic eyes
•The patient has split-bundle anatomy
•The patient has a tilted RNFL bundle pattern
If the patient's temporal RNFL that is very thin or absent, the maps
might show thickened RNFL.
CIRRUS™ HD-OCT compares the RNFL thickness and symmetry of
the scan(s) with the reference range for healthy eyes for the
patient's age.

Attachment B Reference Database 2 for Healthy Eyes Study–CIRRUS 6000 Instructions for Use
CIRRUS HD-OCT B.8 ONH and RNFL Images
466 /<PHONE_NUMBER>178037 Rev CB.8.1 ONH Parameters
The data originally collected for the database was analyzed to
create the reference ranges for the following ONH parameters:
•Rim Area (mm2)
•Average Cup to Disc Ratio (square root of cup area over disc
area)
•Vertical Cup to Disc Ratio (cup height over disc height)
•Cup Volume (mm3)
B.8.2 RNFL Parameters
This study determined the reference range for healthy eyes for the
following the retinal nerve fiber layer (RNFL) parameters in healthy
subjects ages 18 to 88:
•Average RNFL Thickness
•Temporal Average RNFL Thickness
•Superior Average RNFL Thickness
•Nasal Average RNFL Thickness
•Inferior Average RNFL Thickness
•Inter-eye symmetry (RNFL)
•Clock hour parameters
•TSNIT Profiles
•Neuro-Retinal Rim
•RNFL Thickness
•RNFL Deviation Map
B.8.3 ONH and RNFL Data
Type
Variablen Mean (SD) 95% CI Min Max
ONH
Rim Area (mm2) 854 1.30 (0.23) [1.28, 1.31] 0.74 2.21
Average Cup/Disc Ratio 854 0.46 (0.17) [0.45, 0.47] 0.06 0.74
Vertical C/D Ratio 854 0.44 (0.16) [0.43, 0.45] 0.05 0.75
Cup Volume (mm3) 854 0.13 (0.12) [0.12, 0.14] 0.00 0.70
RNFL Thickness
Average RNFL Thickness (µm) 854 93.19 (9.28) [92.57, 93.81] 69.00 126.00
Temporal (µm) 854 64.04 (11.53) [63.26, 64.81] 40.00 120.00
Superior (µm) 854 115.05 (15.92) [113.98, 116.12] 72.00 162.00
Nasal (µm) 854 72.35 (11.54) [71.58, 73.13] 41.00 115.00
Inferior (µm) 854 121.37 (16.08) [120.29, 122.45] 72.00 188.00
Clock hour 1 (µm) 854 105.56 (23.11) [104.01, 107.11] 51.00 185.00
Clock hour 2 (µm) 854 88.60 (18.10) [87.39, 89.82] 43.00 160.00
Clock hour 3 (µm) 854 60.73 (10.53) [60.02, 61.44] 38.00 103.00
Clock hour 4 (µm) 854 67.78 (13.79) [66.85, 68.70] 37.00 129.00"<|eot_id|><|start_header_id|>user<|end_header_id|>

What is RNFL Clock hours in ONH and RNFL OU Analysis?

Answer the question and provide additional helpful information,
based on the pieces of information, if applicable. Be succinct.
End the response with tag which is must.

Responses should be properly formatted and structured so that it can be easily read.
Helpful and the most accurate response from the context and relevant to question :- <|eot_id|><|start_header_id|>assistant<|end_header_id|>
"""
# print("Full Prompt:")
# print(prompt)
for chunk in llm.create_completion(
                        prompt,
                        max_tokens=4096,
                        # top_k=40,
                        # top_p=0.95,
                        # min_p=0.05,
                        # frequency_penalty=0.0,
                        # presence_penalty=0.0,
                        # repeat_penalty=1.1,
                        temperature=0,
                        # seed=2000,
                        stream=True,
                        echo=True,
                        ):
    print(chunk["choices"][0]["text"],end="", flush=True)

Relevant parts
<|start_header_id|>system<|end_header_id|>
new line here < important
Use the following pieces of information to answer the user's question.
If you don't know the answer, just say that you don't know, don't try to make up an answer.
Context: Instructions for Use Attachment B Reference Database 2 for Healthy Eyes Study–CIRRUS 6000
..................................................................................................................................................................................................................
Clock hour 4 (µm) 854 67.78 (13.79) [66.85, 68.70] 37.00 129.00"<|eot_id|><|start_header_id|>user<|end_header_id|>
new line < important
What is RNFL Clock hours in ONH and RNFL OU Analysis?
Answer the question and provide additional helpful information,
based on the pieces of information, if applicable. Be succinct.
End the response with tag which is must.
Helpful and the most accurate response from the context and relevant to question :- <|eot_id|><|start_header_id|>assistant<|end_header_id|>

Thanks a lot @i486 ,This solved my issues.
This was a great learning.


impl(bigquery): do not use output only fields in input json payload.

Some of those fields are objects which contain fields, required by BQ API. Even if it's not used by it. Documentation states that these fields are output only, which should be save enough to remove it from serialization process (to_json function).
https://cloud.google.com/bigquery/docs/reference/rest/v2/Job

This change is

/gcbrun

I fixed formatting and updated PR title.

/gcbrn

I close this PR as it fixes the issue only partially.
Full fix (making the library smart enough to populate json with only required values) is going to take too much time. It can be done in future.


Publishing issue

Hi, on the latest beta, attempting to publish results in the error "The "InputAssemblyPath" parameter is not supported by the "ConvertErrors" task. Verify the parameter exists on the task, and it is a settable public instance property"

I'm using .NET Core 3.1 and Functions 3.

Was this from the command line on Windows?

yep, this was on windows with VS Code.

Ahh ok thank you. Someone else has reported a problem on Code on Mac.
I think I know what's wrong - I'll get a fix out in beta3 (which shouldn't be far off).
Thank you!

No worries. Thanks for looking into it! Thankfully, there's a bit of a workaround where you can just ignore the error and continue the publish for the time being.

I was having the same issue, though, mine is happening w/in Azure Devops CI Pipeline.  I switched back to trying to use 3.0, and get an error where it couldn't locate service bus.
dotnet 3.1 error (matches error @robcwaldron

switched back to 3.0, and getting the following error now:

Does anyone else using Azure CI?  Example of the CI yaml:
`trigger:

develop
staging
uat
master

pool:
vmImage: 'windows-latest'
steps:
#install giversion nuget to assist with setting versions in place
note, the released one doesnt work in ubuntu and has to be used using beta release of 5.0

script: |
dotnet tool install --global GitVersion.Tool
displayName: "GitVersion Setup and Run"

task: DotNetCoreCLI@2
displayName: 'dotnet restore from feed'
inputs:
command: restore
projects: '**/*.csproj'
vstsFeed: 'XXXXXXXXXXXXXX'
includeNuGetOrg: true
versioningScheme: byBuildNumber

task: DotNetCoreCLI@2
inputs:
command: publish
arguments: '--configuration Release --output publish_output'
projects: 'src/MotionCX.WorkfloEventStore.FunctionTest/MotionCX.WorkfloEventStore.FunctionTest.csproj'
publishWebProjects: false
modifyOutputPath: true
zipAfterPublish: false

task: ArchiveFiles@2
displayName: "Archive files"
inputs:
rootFolderOrFile: "$(System.DefaultWorkingDirectory)/publish_output"
includeRootFolder: false
archiveFile: "$(System.DefaultWorkingDirectory)/build$(Build.BuildId).zip"

task: PublishBuildArtifacts@1
inputs:
PathtoPublish: '$(System.DefaultWorkingDirectory)/build$(Build.BuildId).zip'
artifactName: 'drop'

I've restored the v3 method of working with paths in the targets and published that as part of beta 3 - its on NuGet now. Let me know if that helps!

I believe this is now fixed in v4.0.44-beta.4  but any more issues give me a shout!


Critical database failure

We have had an issue with the database that is going to require getting back to a prior backup

Roughly:

Start accidental db migration at about 18:13 (GMT)
Recovered db to 17:55
App back up by 18:35

Looks to be one user who signed up during that process, there was someone who started a subscription but that is correctly hooked up now too.


TAP Support

Hello. Great library. I'm not sure if TAP is supported. If it is not, why not support it, as it is a standard protocol and being used by nearly all other sweet minimalistic testing libraries?
Another benefit would be to compose tead with other TAP supporting utilities already available.

@gwn alternate output formats are not currently supported, but if that does land TAP would be a great custom reporter to write. See #11.

@gwn if you wish to keep pushing this proposal forward, please do so in existing issue #11.


Implemented: functionality to add support to select eComStore from settings page (#251xhvt).

Not applicable now. This is already done


Failed to save addon configuration - missing option adapter: zigate

zigbee2mqtt add-on version (if edge, please report commit hash): <IP_ADDRESS>
Operating environment (HassOS, Virtual Machine, Device/platform running Home Assistant): HassOS
Description of problem:
Hello,
I simply try to setup the addon with the adapter: zigate option according to https://www.zigbee2mqtt.io/information/supported_adapters.html#zigate-usb-ttl .
When i do so, I get the folowing error when saving the config:
Failed to save addon configuration, not a valid value for dictionary value @ data['options']. Got {'data_path': '/share/zigbee2mqtt', 'external_converters': [], 'devices': 'devices.yaml', 'groups': 'groups.yaml', 'homeassistant': True, 'permit_join': False, 'mqtt': {'base_topic': 'zigbee2mqtt', 'server': 'mqtt://<IP_ADDRESS>:1883', 'user': 'broker', 'password': 'XXXXXX'}, 'serial': {'adapter': 'zigate', 'port': '/dev/serial/by-id/usb-Silicon_Labs_ZiGate_0001-if00-port0', 'baudrate': 115200}, 'advanced': {'log_level': 'info', 'pan_id': 6754, 'channel': 11, 'network_key': [1, 3, 5, 7, 9, ...

I guess that the zigate option is not yet implemented in the module ? Just for the sake of trying, with the adapter: deconz, the configuration will save correctly
thanks
Your entire configuration from the frontend (with sensitive fields redacted):
data_path: /share/zigbee2mqtt
external_converters: []
devices: devices.yaml
groups: groups.yaml
homeassistant: true
permit_join: false
mqtt:
  base_topic: zigbee2mqtt
  server: 'mqtt://<IP_ADDRESS>:1883'
  user: broker
  password: x
serial:
  adapter: zigate
  port: /dev/serial/by-id/usb-Silicon_Labs_ZiGate_0001-if00-port0
  baudrate: 115200
advanced:
  log_level: info
  pan_id: 6754
  channel: 11
  network_key:
    - 1
    - 3
    - 5
    - 7
    - 9
    - 11
    - 13
    - 15
    - 0
    - 2
    - 4
    - 6
    - 8
    - 10
    - 12
    - 13
  availability_blocklist: []
  availability_passlist: []
device_options: {}
blocklist: []
passlist: []
queue: {}
frontend:
  port: 8099
experimental:
  new_api: true
socat:
  enabled: false
  master: 'pty,raw,echo=0,link=/dev/ttyZ2M,mode=777'
  slave: 'tcp-listen:8485,keepalive,nodelay,reuseaddr,keepidle=1,keepintvl=1,keepcnt=5'
  restartdelay: 1
  initialdelay: 1
  options: '-d -d'
  log: false

Your logs from Home Assistant

@kbouh320 Seems this option is missing:
https://github.com/danielwelch/hassio-zigbee2mqtt/blob/master/zigbee2mqtt/config.json#L103
This will have to be corrected with a new release. I will try to include this together with https://github.com/danielwelch/hassio-zigbee2mqtt/issues/499

@ciotlosm great thank you

This is now part of https://github.com/zigbee2mqtt/hassio-zigbee2mqtt 1.17.0
I'll also accept the PR on this as soon as I get sometime to rebase it for 1.17.0

This is now part of https://github.com/zigbee2mqtt/hassio-zigbee2mqtt 1.17.0
I'll also accept the PR on this as soon as I get sometime to rebase it for 1.17.0


forgejo-cli: add BUILD_TYPE env & move to new darwin pattern

At the request of the maintainer of fj i added the BUILD_TYPE env. You can observe this with fj version --verbose
And moved to the new darwin pattern
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

nixpkgs-reviewd workflow started

Extra args: ``
Free space: true
Who asked: lucasew

TARGETS

x86_64-linux: true
x86_64-darwin: true
aarch64-darwin: true

Status and logs: https://github.com/nixosbrasil/nixpkgs-reviewd/actions/runs/12449927190

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 366849

x86_64-linux

:white_check_mark: 1 package built:

forgejo-cli

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 366849

aarch64-darwin

:white_check_mark: 1 package built:

forgejo-cli

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 366849

x86_64-darwin

:white_check_mark: 1 package built:

forgejo-cli


Teams - Skype Consumer interop

Despite having turned on the "Users can communicate with Skype users" option for several weeks, it is still not possible to communicate with a Skype user based on its live account email (@hotmail.com)
is there any specific tricks to solve the issue or any logs to identify the problem ?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 3de87096-6253-ba71-f27a-0b161a36f0e2
Version Independent ID: 8b61b40d-496c-6069-8a60-38a6282e072a
Content: Teams and Skype interoperability - Microsoft Teams
Content Source: Teams/teams-skype-interop.md
Service: msteams
GitHub Login: @LanaChin
Microsoft Alias: v-lanac

@SwissChoko
thank you for submitting feedback.
I think the best way forward is if you open a service ticket in your tenant so this can get resolved ASAP. Based on the outcome let me know if it is something that can be called out in the docs.
Please follow this link to contact support for business products:https://docs.microsoft.com/office365/admin/contact-support-for-business-products
Please keep us posted here on the resolution so we can feed whatever information you discover into the content.